Add the ability to enable/disable a channel over WiFi

[elkablo]

Currently the only way to enable or disable a channel's power is by pressing a button. It can be useful to be able to do it via Wifi.

For the ability to work, the user needs to configure it via serial command line. There, it can be:

• allowed from any IP address,
• allowed from IP address of the logging server,
• forbidden.

To enable or disable a channel's power via WiFi, an UDP packet containing an 8 bytes long message (enblChnN or dsblChnN) must be sent to the SmartPower3 device IP address, UDP port 3333.

This can be done for example with the socat utility:

echo -n enblChn0 | socat stdin udp-sendto:IP_ADDRESS:3333

The ability to toggle a channel's power can be useful for:

• Remote debugging. My SmartPower3 is at my office, powering devices that I am working on. I am developing U-Boot / Linux kernel drivers on these devices. Sometimes I need to disable the power for the device completely. Another plus is that when I am done working, I want to disable the power to the device completely, for safety.
• Automatic testing / CI. For example the U-Boot bootloader is actively developed, there are many changes being merged every week and these changes need to be automatically tested. Some devices need to be completely powered off/on to enter a mode that allows to upload firmware via serial. Having the ability to automatically power cycle a device is therefore helpful for automatic testing.

[tomek-szczesny]

#35
?

[elkablo]

@tomek-szczesny do I understand it correctly that #35 adds this functionality, but only over TCP? Anyway, that merge request should be split into at least 2: one adding the DHCP changes and the other adding SCPI functionality. Also there should be a description about what is being supported.

What is SCPI by the way? Is it standardly used for configuring network connected power supplies? I have never heard of it, but I am not that much of a hardware guy.

[tomek-szczesny]

I'm not entirely sure how complete is that pull request, it's labeled as draft. I hope @cedel1 could shed some light on it.

SCPI is a de facto standard language of lab instruments remote control, including power supplies. My Korad bench PSU understands these commands through RS-232, and my Rigol scope accepts the same language through Ethernet or USB. I believe it's been around since the 80s.

EDIT: One of @cedel1's commits is the manual.

[cedel1]

Hello, @elkablo , @tomek-szczesny,

the #35 is pretty much complete, except for one trouble - I occasionally ran into not having enough memory - and seeing almost nowhere to optimize further. And since there did not seem too much interest (at least in testing it) and I landed a new full-time job, I sort of forgot about it.

As to splitting it into 2 PRs - from checking point of view, that would make perfect sense. From my development point of view, that is a bit problematic, because of the memory issues (once I started to run out of memory, I started looking at all possible places to save some and touched a lot of pieces of code).

Anyway, if you want to try the code from that PR, you can download and check binaries and manual from my repo at https://github.com/cedel1/smartpower3/releases/tag/dhcp_and_scpi_alpha .

[elkablo]

Hello @cedel1,

my guess for the reason of those memory issues would be TCP.

Anyway, I have no reason to try it out since I now have a working and simple solution for my problem. But maybe for the future, what client do you use for the SCPI protocol? Is there some small, reasonable command line utility?

Thanks.

[tomek-szczesny]

SCPI is human readable and writable, there's no need for a CLI tool. It's more of a standardized syntax than a protocol.
You've basically done the same, except you used non-standard command syntax, and implemented only one functionality (channel on/off).

I personally use SP3 as a standalone device for now..

[cedel1]

Hello @elkablo ,

that may be that it is caused by TCP, there were many issues before (more fonts than necessary, extensive use of Strings without reserving space (thus causing a lot of memory fragmentation), menus, etc.

The unfortunate thing is that the debug pins are used for other purposes, so debugging the issues is not so simple.

You can use most any SCPI client (as well as text). The best part is that there exists Python library for SCPI, so one can program the measurements any way they see fit (within the limits of the implementation, of course), maybe generate graphs directly from the Python program etc. There is one or two examples in the manual.