SmartPower3 remote control (SCPI)

[cedel]

I've started looking into controlling SmartPower3 remotedly, via SCPI.

So far I've got a SCPI library (at least partially) working and can experimentally control some of the SP3 functionality via Serial. But (of course) I've ran into some problems, mainly regarding how all this functionality should be "wired" together.

So I would like to ask you for your help and ideas on this subject. I think I can code the thing but would love some ideas and help regarding at least the following questions:

1. How should the SCPI command tree look? (What should be the structure of the commands - what I've got so far is below.)
2. How to connect the various functionalities, ie what should be the relation of the current standard logging output to the SCPI commands output? Should there be two or more modes? Or do we create SCPI extension command that would output the current logging via different output? Or use LAN - one port for control, other port for responses and/or logging output? And retain backwards compatibility, so tools are not broken.
3. What to do with the WiFi menu currently blocking Serial interface?
4. What to do with status registers? (Status:Questionable, Status:Operation etc.) - currently, I am inclined to leave this out until the other problems are solved.
5. Should the device be modeled as having multiple independent instruments (which sort of makes sense, since the outputs are separate and not logically interconnected) or having channels?
6. How should the protection bits be reported?
7. How should the output power (Watts) be reported?
8. Do we add Bluetooth serial (if possible) as another connection method?
9. How should all this be controlled (modes and settings changed, what should be on display etc.).

I am working of the SCPI documentation located at https://www.ivifoundation.org/docs/scpi-99.pdf.


So, what do you think? And thank you for your help.


[optional]:required

/* IEEE Mandated Commands (SCPI std V1999.0 4.1.1) */
"*CLS"
"*ESE"
"*ESE?"
"*ESR?"
"*IDN?"
"*OPC"
"*OPC?"
"*RST"
"*SRE"
"*SRE?"
"*STB?"
"*TST?"
"*WAI"

/* Required SCPI commands (SCPI std V1999.0 4.2.1) */
"SYSTem:ERRor[:NEXT]?"
"SYSTem:ERRor:COUNt?"
"SYSTem:VERSion?"

"STATus:OPERation?"
"STATus:OPERation:EVENt?"
"STATus:OPERation:CONDition?"
"STATus:OPERation:ENABle"
"STATus:OPERation:ENABle?"

"STATus:QUEStionable[:EVENt]?"
"STATus:QUEStionable:CONDition?"
"STATus:QUEStionable:ENABle"
"STATus:QUEStionable:ENABle?"
"STATus:PRESet"

/* Non required SYSTem commands */
"SYSTem:CAPability?"

"INSTrument:NSELect"
"INSTrument:SELect"

/* measuring after instrument selection has been made */
"MEASure[:SCALar]:VOLTage:DC?"
"MEASure[:SCALar]:CURRent:DC?" ?

"[SOURce]:CURRent" // set amps
"[SOURce]:VOLTage" // set volts

"OUTPut[:STATe]"
"OUTPut[:STATe]?"

[mctom]

Hello,

I trust you already know some of my opinions on SCPI, just wanted to quickly address a few of the newer questions.

I feel that two outputs of SmartPower3 would be easier to use (and to program) if treated as "channels" from SCPI perspective. The INST approach is also valid and I think I've seen it in Rigol PSU in the past. SCPI was always meant to be stateless, so previous commands should have minimum impact on the outcome of the next, outside of operating the instrument itself.

So for each channel "n" (if not defined, channel 1 is always assumed)
Set voltage - SOURce<n>:VOLTage 12
Read voltage setting: SOURce<n>:VOLTage?
Read voltage measurement: FETCh:{SCALar]:VOLTage[:DC]? CH<n>

The same for currents, if setting current makes any sense at all.

There is a command for measuring power as well:
FETCh:[SCALar:]:POWer[:DC]? CH<n>

Why FETCh and not MEASure? Because by convention, FETCh returns data that already exists in instrument's memory, so it happens instantaneously. MEASure triggers acquisition of new data point and returns it, so it may take up to one SP3's interval to get a result. However it guarantees that each MEAS command returns a different data point (consecutive, if issued fast enough).
Both may be implemented, but I'd start with FETCh.

I am aware this is inconsistent syntax between SOUR and FETC, regarding channels, but that's how I remember it. Looks like it would make more sense to add a channel number as a suffix of FETCh, but I can't find an example of such use.

And OUTPut command:
OUTPut[:STATe] 1, CH<n>
OUTPut[:STATe]? CH<n>

Let me have this opportunity to congratulate you yet again on your amazing work with SP3 firmware.

[cedel]

I am sorry for my late reply.

SCPI was always meant to be stateless

I don't know what the original author(s) of the SCPI had in mind, but from the spec itself it seems to me that is not actually the case - please have a look at the 4.1.3.1 "Overlapped and Sequential Commands" and all the registers etc.

Channels versus logical instruments - please see chapter 6.2.5 "Multiple Capabilities and Numeric Keyword Suffixes" and its subchapters. From that point of view it makes sense to use channels instead of logical instruments, because otherwise it seems to be necessary to implement all the states and registers 3 times (two outputs and input). Hope the channel numbers won't be a problem - I haven't tried that yet.
On the other side, that means that to take a measurement one would have to use the whole command "SOURce<n>:VOLTage[:DC]?" instead of just "VOLTage", since the channel has to be specified each time for every command - as opposed to the logical instrument (INST) approach, where it is set before the command and then all subsequent commands operate on that "instrument" until it is changed.

Then there's a use-case of making a possibly fatal error - what happens, when a user tries (after some other commands) to set output voltage on channel 2 and accidentally forgets to write the channel number? That could easily lead to "frying" their powered computer on channel 1 if the source was turned on. I can imagine it's not so much of a problem if data are read from wrong channel of, let's say, an oscilloscope, but setting possibly fatal output value on a power supply, that's something else.

Why FETCh and not MEASure? Because by convention, FETCh returns data that already exists in instrument's memory, so it happens instantaneously. MEASure triggers acquisition of new data point and returns it, so it may take up to one SP3's interval to get a result. However it guarantees that each MEAS command returns a different data point (consecutive, if issued fast enough).
Both may be implemented, but I'd start with FETCh.

The instrument model is described in chapter 2, "Instrument Model" of the "1999 SCPI Command Reference" and the difference between FETCh and MEASure is well described in chapter 3, "Measurement Instructions".
So I have to say that while what you wrote is correct, it is a bit more complicated. To me, it makes more sense to implement MEASure, since it is just "one" command and does not necessarily require the other commands (Initiate etc.). FETCh basically seems to be a lower level command - and there's no voltage memory present (programmed) into SP3.

Also, it follows the basic implementation of Power Supply as described in "1999 SCPI Instrument Classes", chapter 7, "Power Supplies". Some useful info is also found in chapter 3, "Digital Meters".

It seems it is possible to output stream of data via SCPI. It's a little bit more complicated but have a look at the FEED command.


Currently, I have tried to roughly implement some more SCPI commands (setting network settings) and I am trying to design/figure out the settings - control of the SP3 (setting the various modes etc.), while keeping it backwards compatible. So back to Serial menu and WiFi manager

[mctom]

Sorry I won't dive too deep into the documents at this time, but I've got a few comments off the top of my head.

First of all, I would lean towards design choices that minimize the amount of extra registers in software. So indeed, instead of instruments I feel that channels make more sense.

There are already variables that hold the last measurement result, I think?
My reasoning was that FETCh may return these values immediately, and MEAS could wait until the next sample is being collected, and then return the fresh results. I wasn't aware of things going on behind the scenes when you use either of those commands, just vaguely remember the difference in how they worked for the end user.

The problem with implementing MEAS only is that you won't be able to fetch a few variables from the same sample. For example, get voltage and current of one and the same sample would be impossible. This is what we used one MEAS and multiple FETC commands back in a day.

Possibly fatal errors resulting from misuse may just as well emerge in INSTR scenario - someone added something in a middle section of the script, in which he switched instrument number, and the following commands will be executed on a wrong SP3 channel. Since SCPI is predominantly a scripting language, I wouldn't mind longer, but unambiguous commands.

When no channel number is provided, I think it should default to CH1. Can't see a problem with this either, as long as this behavior is consistent.The first Terminator movie wasn't called Terminator 1 and yet we know it was the first one. The question is, does GUI acknowledge which output is which, in terms of numbers? We are used to calling the leftmost thing the first, might not be the case in all cultures.

[cedel]

I'm sorry for the delay in communication - this is just a quick head's up.

After implementing extra screen with DHCP/network settings and new serial menu (you know, the current one only takes one number as a selection so the number of options is limited) I've ran into memory problems (or, rather, lack of memory) so that had to be adressed first.
I've made some progress on this front (discarding/unifying some less useful strings and mainly optimization of the amount of stack size the individual tasks are assigned) and I hope I am back on the track of implementing the actual SCPI commands - but that will take some device memory too, so I hope it works out in the end.

More details (and reasoning) soon to follow, hopefully.

[mctom]

Maybe you could remove one of the fonts to save more memory, after all.
I wonder why memory is such a problem. Hopefuly that's not because of my circular current buffers. How much memory is there anyway? In range of single MBs, I assume?

[rooted]

Couldn't you just use heatshrink?

[cedel]

@mctom

Maybe you could remove one of the fonts to save more memory, after all.

Right now, there's only NotoSansBold (at roughly 15Kb) being included explicitly. TFT_eSPI probably includes some other fonts, but I've stripped all the easily removable and unused fonts during the first update. If I remember correctly, there were no other unused fonts to strip easily, but I can definitely check once more.
Another option I thought about was to check if I cannot make the font smaller (remove unused characters), but the size (compared to the other fonts that I've tried in the previous versions) seems to be about the right size for latin-1 charset.

I wonder why memory is such a problem.

Hmm, maybe I should elaborate on that - at least the way I see it
Unfortunatelly, I haven't been able to run/step through the firmware with hardware debugging enabled, so I am left with printouts etc, basically being half blind.

From what I have figured out, I can divide it into two main areas:
1. static (or near static) allocations - the objects that get created at startup, during setup and main loop. That would include all the global variables, individual task stack allocations, event queue etc.
2. dynamic allocations - some of the screen mechanism parts get initialized when the screen is first displayed (and then should basically remain static), when some text is redrawn, the font needs to be loaded (15Kb used and then freed after the draw), WiFi library allocates IO buffers when WiFi is turned on (and deallocates them when turned off) and I think that might apply to other libraries as well.

How much memory is there anyway? In range of single MBs, I assume?

I wish My IDE reports "HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash"

So what I have done (at least temporarily, regarding the memory usage) is to:
1. reduce the stack size allocations of some of the tasks I was easily able to measure (using printouts) to more reasonable sizes - there's basically no reason to have double or triple the required size, if the task should not grow in size (short of wrong memory usage, in which case the problem should be fixed first) - like the input and buffer tasks.
2. Used F() strings whereever possible
3. Unified some of the strings, especially in the new menu (using the F() function I can prevent having copies of every string in memory, but if the string gets displayed, it will eventually be loaded, if I remember correctly - so having "Operation succeeded" and "Operation failed" instead of specialized wording is more RAM and Flash efficient.
4. Regarding the circular buffers - they are 1000 float samples per channel (3000 float numbers all together), with ~3.5KB per channel. But the results are passed as unit16_t - basically, half that size. The way I understand it is that doing the maths with float numbers and then casting to lower precision number leads to more precise result during rounding the numbers. But the buffer size... So during the development, I've made the samples uint16_t - making the buffers half the size in RAM. Will return them to be float when I am finished and it is possible.
5. Switched of some optional extended error enums in the SCPI library.

Currently, with the above changes, the largest symbols are the font and four print functions from libs (_vfprintf_r et al).

I'll look at more optimizations when done with the SCPI or when/if needed. As was once said - "Premature optimization is the root of all evil"

@rooted

Couldn't you just use heatshrink?

Thank you for the tip. I had a (superficial) look at the library and it looks interesting, but the way I see it now that won't help much. Currently I am having problems with RAM consumption, not storage consumption. The Flash storage is pretty much used up as well, but there's still the possibility of changing the partition table and reclaim space from unused partintions.

[mctom]

Hm, that'd be interesting to know what takes all that memory, because reducing circular buffers saves about 1%.

I think the circular buffers can be reduced to 500 samples.
Assuming that the slowest interval is still 1000ms. The code assumes that free running sampling rate is always above 500 samples per second, which means it grabs (interval[ms] / 2) samples for averaging. That's 500 samples max.

If you want to keep the circular buffers 16-bit that's fine with me, but please do one of the two:
- Use 16-bit floats (if supported)
- Make sure the currents are stored in mA rather than Amps in the circular buffer (I can't tell what's the current status, the units are all over the place in the source code).

I wouldn't expect any impact on accuracy with 16-bit buffer, fully agreed.

[cedel]

Hm, that'd be interesting to know what takes all that memory, because reducing circular buffers saves about 1%.

Exactly, but without being able to examine the memory at runtime (I haven't figured out a way to attach debugger to SP3 yet), it's just poking, printing and educated guess.
I figured out the memory problem when the WiFi wouldn'ŧ load one time, complaining about not being able to allocate buffers. Part of that will be the platform files themselves, screens etc, etc.

If the font is 15Kb and the 4 print functions take ~10Kb each, that that's approximately 55Kb - ~1/6 of the whole RAM...

I think the circular buffers can be reduced to 500 samples.

That's good to know, thank you

If you want to keep the circular buffers 16-bit that's fine with me, but please do one of the two:
- Use 16-bit floats (if supported)
- Make sure the currents are stored in mA rather than Amps in the circular buffer (I can't tell what's the current status, the units are all over the place in the source code).

- No 16-bit (2 byte) floats for esp32. float on esp32 is 4 bytes long. That's why using uint16_t makes the buffer effectively half the size.
- That's exactly what I did - the measurement methods return V and A as floats (if I remember correctly), but since the measurement cannot go above ~32V and single digit Amps, and negative values won'ŧ happen (the manual says that PAC can measure negative voltages, but only to some -200mV and even then it has to be specifically enabled - which isn't the case, if I looked at the correct place), I assumed that it's safe to use 0-65535 for mA and mV (there should not be any value overflow) and store those values in the buffers.

But it's not exactly true there would not be ANY impact on accuracy - not a major impact, that is true. I imagine there might be slight differences due to what numbers are rounded (if the result is counted as higher precision float numbers from the buffers and then rounded to 16-bit or if the computation is done with numbers already rounded to 1/1000).

[rooted]

To debug you would need to breakout the jtag pins (if they aren't already) and use the ESP-Prog device.

https://www.instructables.com/How-to-Us ... -an-ESP32/


I'm sure you already know this however.

[cedel]

I expected something like that would have to happen - looking at the photos of the SP3 board on the product page, some time ago, I even think they might be broken out on the board and it would require only soldering pin header for the connection. I could try to do that (and would probably succeed in the soldering), but... I could easily destroy my device if things go awfully wrong and with the prospect of not being able to buy a new SP3 soon... let's just say that is a risk I am not prepared to take just yet for the purpose of proving that I can do it.

I was hoping that there might be a way to do that via Serial debug via the CP2102 converter that I have missed or misconfigured - I've read that some of the ESP32 boards have this or similar option. But probably not this one.

[mctom]

Looks like all JTAG pins of ESP32 are used for critical signals in SP3, so that won't work anyway. I mean, there's no point debugging it if JTAG is disrupting internal I2C and toggling one channel on and off.

I don't know anything about software controlled debug via UART but that would be helpful if it worked.

[cedel]

Hello, sorry for the long break.

Finally, I've put together something that I think works. But since I am getting "professionally blind", I would be grateful if you could have a look, test and report possible problems and required enhancements.

I've made a draft pull request at SP3 repo (https://github.com/hardkernel/smartpower3/pull/35), an alpha "release" in my repo (https://github.com/cedel1/smartpower3/r ... scpi_alpha) so to test there's no need to build from source yourself - just grab the binary and "update" the way standard firmware update is done (https://wiki.odroid.com/accessory/power ... t_firmware). But should you want to build from source, you can, of course.

The main changes are as follows:

1. Reworked serial menu - it now has 2 levels and is structured slightly differently (needed because of the growing number of options available).
2. Another settings screen was added - this allows to enable or disable DHCP and view static IP address, subnet mask, gateway IP Address and DNS servers. These values can be set via default mode serial menu.
3. Build version on the original settings screen was replaced by operation "Mode", allowing to choose between original/default mode and SCPI mode. The build info was moved to the new DHCP settings screen (there was more space there).
4. SCPI functionality was added. Should enable most of the same functionality as the default mode and some more, but currently misses 2 functions - setting the logging interval and changing the operation mode (I have yet to figure out a sensible SCPI command structure to enable it).
5. When in SCPI mode, the screen buttons don't lock, so changing values via encoder should still be possible.
6. The SCPI part comes with a small pdf manual describing the available commands and usage. Can be downloaded from the release page. It is based on latex so I also made it part of the repo - so any subsequent changes can be reflected in the manual.

Please bear in mind that this is alpha software and there are no guarantees. It might eat your children, but it didn't bite me yet, so you should be fine, if the standard precautions regarding SP3 are observed.

So, what do you think? Any bug reports and/or suggestions?

[mctom]

I saw that pull request earlier today, but I'm so overwhelmed with work right now I can't even cope with contributions to my own project at the moment.
I'll take a look at what you've done in spare time (lunch break at work? ) and hopefully provide a meaningful feedback.

Meanwhile, I think it would be awesome to put together an include an example script that drives SP3 using SCPI commands. Could be a Python script, why not.

For example, it could be a voltage sweep, starting from the lowest possible and making minimal steps. On each step, voltage and current would be measured and recorded. If power exceeds 0.25W, it should stop.
Returning data as a CSV table in command line, that could be imported into a spreadsheet. Samples should be well averaged, 100ms acquisition time would be OK.
I would say this could be a very elegant way of making U/I characteristics of diodes and other devices, but unfortunately SP3's hardware don't go below 3V IIRC. But nevertheless, a fun experiment. What will a 12V light bulb produce?

After all, SP3 was advertised as a tool for embedded low power engineering, so voltage sweeps are the best way to figure out which voltage yields the lowest losses.

[cedel]

Thanks for getting back to me I totally understand your lack of time, so I'll be glad for any menaingful feedback.

The sample python script is a great idea, thanks for putting that forward!