PicoC capability for 'on-the-fly' data modification?

[Tico]

I have a need for a 'man-in-the-middle' hack of an RS232 data stream.

The RS232 link has a baud rate of 9600bps and, amongst other data, sends 8 serial numbers that need to be changed. The RS232 link is at an early 'basic' stage of a comms link between a Battery Management System and an inverter.

The closest possible solution I can find is a Windows program called Termite -

https://www.compuphase.com/software_termite.htm#FORWARDDATA

I wish to understand whether a Loxone Miniserver/PicoC program has the horse-power to do this 'on-the-fly'?

The background to the issue is a solar battery bank that's been modified to have two separate swap-able banks. The problem is caused by changing serial numbers being registered by the BMS on switch-over and subsequent unwanted behaviour.

The issue could be solved if I can intercept the 8 separate serial numbers and change them to duplicate an existing set of serial numbers on the other battery bank. The solar battery is already integrated with the Loxone system using Modbus for reading various parameters. Unfortunately, the unwanted behaviour is not resolvable by Modbus command. It needs resolving at a 'lower' level in the comms path.

I have experience with a UART to TCP converter I use for an unrelated device connected to the Miniserver. This device converts data into a UDP stream than flows into the Miniserver. Single commands can also be sent back to the device by Virtual Output.

I would anticipate a possible architecture would consist of an initial UART to TCP converter sending a UDP stream into the PicoC program, parsing the data for the 8 serial numbers (each serial number being 8 characters in a range 12013324, 12013325, etc.), then forward the modified data as a UDP stream to a second TCP to UART converter in the comms path between the BMS and the inverter. The flow is bi-directional at ~95% upstream and 5% downstream.

I have limited experience with PicoC, but is this remotely feasible as a concept given the limitations of the Miniserver/PicoC?

[Andrew B]

How frequent are the messages?

In principle this should be doable in picoC, although it can be a pain to debug.  I found performance of my much more substantial pile of picoC wasn't a problem, and I had 4 scripts running and doing more work that you're proposing.

[Tico]

The various values on a web-monitoring application for the inverter change every 10 seconds. For example, the parameter 'charge rate' in kW's going into the battery updates at 10 second intervals. But the underlying data may be flowing in much more quickly.

There's about 72 unique parameters coming out of the battery/BMS combination (8 battery modules by 9 fields). I've just purchased two USB to serial converters to set up the Termite application so I can properly observe the data flow and have a more accurate assessment.

[Andrew B]

Well its not more than ~960 bytes per second, right?  That should be doable, at least if you're a bit careful about how you write the picoC.  Do as much work as possible with the library of functions they provide -- those are BLAZING fast compared to the code you write in picoC.  In this cast strstr() is probably your friend.  You can probably also batch up the messages into larger blobs so that you have to run your logic less often (depends on how tolerant the receiving engine is of that, of course).  And remember it is interpreted, so stupid things like shorter variable names, removing white space, etc actually does make it faster.  I sped up one of my programs by more than 2x by trimming down the text of the script!  

Why o why o why don't they provide either a C *compiler* or a decent language (Lua?)????

[Tico]

Thanks Andrew. That gives me some hope with this work-around option.

I have spent a lot of money on the extra battery modules only to discover this serial number road-block. I've also tried a few different avenues for a work-around to the issue to no avail. The system manufacturer hasn't been very supportive because they don't see the need to expand the system.

Because it is now a modified and expanded system, it will necessarily require some work-arounds which include making the second battery bank look identical to the first.

I should clarify my description of 'limited experience with picoC'. I can cut & paste pre-made picoC scripts into the block and have made basic changes to parameters I recognise. I have no coding experience. I'm happy to engage 'someone' professionally if interested???

[Andrew B]

Just to keep the discussion group informed: I’ve suggested to Tim that it is probably far more sensible to splurge and buy $25-50 ARM-based Linux computer to do this task (and anything else requiring programming) because you will more than recoup the cost of the device in programming time saved. Plus no worries about slowing or destabilizing the miniserver.

I’ve got my miniserver playing watchdog for my Linux device too, although I’m finding that it’s pretty stable.