MPPT VE.direct serial data format

Modifications
, , ,
1

I am setting up an MPII (48/5000) + MPPT250/70 system. I am currently using venusOS on an RPi4B because I had one to hand. I have a kosher VE.Bus <->USB connector for initial config and connection to venusOS. That’s all working nicely, and 'Multiplus II and ‘generic Venus device’ both show up in victronconnect and the VRM portal (after setting that up). However my MPPT device is not being recognised by venusOS, and thus not showing up and thus not being set by the ESS assistant to do the right things.

I am using a standard pl2303 serial adaptor which I have used for many years, and logging data with screen or serial studio (at 19200baud) I am getting packets of about 200 bytes once every second. It’s mostly hex rather than ASCII but I assume that’s OK. But plugging it into the Pi the device is not recognised, so I’m starting to wonder if the serial data I am seeing is as it should be.

Victron world is all new to me apart from what I’ve found out over the last month or so (and there is a lot to learn!) so I may be being dumb here, or maybe not…

So, let me check my assumptions: The output from the MPPT250/70 Tr is 5V serial at 19200 baud, 8N1. Right? (I still get periodic output if I set 9600 baud, but different, see below). And is it ‘real’ +/-9V RS232 or TTL 5V ‘fake RS232’ that so many things use these days? I’ve not actualy got my scope out yet to see. And it is is RS232 not RS485?

The output is essentially hex, not readable ASCII? That’s what I’m seeing, but this doc: https://www.victronenergy.com/upload/documents/BlueSolar-HEX-protocol.pdf says I should see human-readable packets ‘periodically’. How long should I wait for one of those? I’m not seeing any.
The data I am seeing is consistent - with each packet starting with 79,BD,D5 so it looks like plausible data. But that doc says the Id for the MPPT 25/70 is 0xA05B and I never see that in my data, which makes me think it may be corrupt somehow (not sure how - wrong speed, floating voltages?)

The automatic messages should all be the ‘Asynchronous items’ (section 1.2). The example messages seem to show that every messages starts with a colon. i.e hex 3A? and end with a newline (hex 0A). Miune start with 0x79 (‘y’) and end with 0x00 (NULL). So am I in fact seeing corrupt (but consistent) data?

Testing, I can in fact get data at 2400, 4800, 9600, 19200, 38400, 57600 and 115200, but none of it seems to have the right ‘starts with a colon’ format. The bytes and packet-lengths vary, as you might expect. (much shorter packets at lower speeds )

If someone had an example of logged MPPT smartsolar output that would help me work out when I have in fact got this working.

I looked at VE.Direct Protocol FAQ [Victron Energy] but it doens’t specify a baudrate.

Details:
Smartsolar firmware version is 1.64, which is current.

The serial I am using is not isolated so I have not connected up the 5V line as that’s only there to power the MPPT side of an isolated device (right?). I’m just using GND/RX/TX in the classic simple-serial form. I do have 3 more RS232->USB devices which are all 5V tolerant so I could try those but I don’t expect them to do anything different.

I tried 2 other PL2303 adaptors which seemed to give the same results.

Attached are files logging for 3 packets-worth at 9600 and 19200
MPPT9600log.txt (1.9 KB)
MPPT19200log.txt (3.6 KB)

2

Maybe this datasheet helps?

3

That was helpful, thanks. But didn’t clarify the signal levels.

I found I had a TTL to RS232 line driver board lying about (i.e one that actually does +/-9V RS232 rather than the usual +5V signalling. wiring that up to a 4th (!) PL2303 USB->TTL serial cable got me the exact same hex data I’d got from the 3 previous cables.

So I got my scope out to see if the MPPT was putting out 5V or +/-9V serial. It appeared to be putting out 5V TTL. And I could see the serial signals running on it.

So I got rid of the line driver and wired up the 4th PL2303 direct (as GND+RX+TX) just as I had done for the previous 3.

And suddenly I got plausible-looking ASCII data. Finally!

The weird thing is that I have no idea how that’s different to my first 3 attempts. It should be exactly equivalent.

Then I soldered up a long-enough cable (4m) to reach the ‘RpiGX’ using some cat5 twisted-pair, plugged it in and my MPPT device appeared as it should do with no faff. (And now I can use the full power of ESS/DVCC/DESS which is quite exciting.)

All very mysterious. One starts to see why the Victron people get grumpy about DIY cables producing mysterious issues. I still need to sort out some isolation for long-term use.

I’ve have been doing serial comms to embedded boards for 30 years now and it is quite often a pain - especially back in the day of 25-pin serial connectors, and people using things other than 8N1, thus providing innumerable ways of having it not work. But it’s been a long time since I’ve had such a recalcitrant connection, especially when it’s bog-standard 8N1, 3-wire TTL.

All I can do to aid future people having troubles is provide this sample of what 2 packets of the serial data looks like

17:38:08.419 -> 0D 0A 50 49 44 09 30 78  41 30 36 39 0D 0A 46 57  |  ..PID.0xA069..FW
17:38:08.419 -> 09 31 36 34 0D 0A 53 45  52 23 09 48 51 32 33 33  |  .164..SER#.HQ233
17:38:08.419 -> 39 34 4D 39 56 47 0D 0A  56 09 35 32 32 32 30 0D  |  94M9VG..V.52220.
17:38:08.419 -> 0A 49 09 30 0D 0A 56 50  56 09 32 30 30 30        |  .I.0..VPV.2000
17:38:08.451 -> 0D 0A 50 50 56 09 30 0D  0A 43 53 09 30 0D 0A 4D  |  ..PPV.0..CS.0..M
17:38:08.451 -> 50 50 54 09 30 0D 0A 4F  52 09 30 78 30 30 30 30  |  PPT.0..OR.0x0000
17:38:08.451 -> 30 30 30 31 0D 0A 45 52  52 09 30 0D 0A 4C 4F 41  |  0001..ERR.0..LOA
17:38:08.451 -> 44 09 4F 46 46 0D 0A 52  65 6C 61 79 09 4F        |  D.OFF..Relay.O
17:38:08.484 -> 46 46 0D 0A 48 31 39 09  31 38 36 30 0D 0A 48 32  |  FF..H19.1860..H2
17:38:08.484 -> 30 09 37 34 0D 0A 48 32  31 09 32 30 38 0D 0A 48  |  0.74..H21.208..H
17:38:08.484 -> 32 32 09 31 34 37 0D 0A  48 32 33 09 35 33 37 0D  |  22.147..H23.537.
17:38:08.484 -> 0A 48 53 44 53 09 31 37  0D 0A 43 68 65 63        |  .HSDS.17..Chec
17:38:08.490 -> 6B 73 75 6D 09 3E                                 |  ksum.>
17:38:09.419 -> 0D 0A 50 49 44 09 30 78  41 30 36 39 0D 0A 46 57  |  ..PID.0xA069..FW
17:38:09.419 -> 09 31 36 34 0D 0A 53 45  52 23 09 48 51 32 33 33  |  .164..SER#.HQ233
17:38:09.419 -> 39 34 4D 39 56 47 0D 0A  56 09 35 32 32 32 30 0D  |  94M9VG..V.52220.
17:38:09.419 -> 0A 49 09 30 0D 0A 56 50  56 09 32 30 30 30        |  .I.0..VPV.2000
17:38:09.452 -> 0D 0A 50 50 56 09 30 0D  0A 43 53 09 30 0D 0A 4D  |  ..PPV.0..CS.0..M
17:38:09.452 -> 50 50 54 09 30 0D 0A 4F  52 09 30 78 30 30 30 30  |  PPT.0..OR.0x000017:38:08.419 -> 0D 0A 50 49 44 09 30 78  41 30 36 39 0D 0A 46 57  |  ..PID.0xA069..FW
17:38:08.419 -> 09 31 36 34 0D 0A 53 45  52 23 09 48 51 32 33 33  |  .164..SER#.HQ233
17:38:08.419 -> 39 34 4D 39 56 47 0D 0A  56 09 35 32 32 32 30 0D  |  94M9VG..V.52220.
17:38:08.419 -> 0A 49 09 30 0D 0A 56 50  56 09 32 30 30 30        |  .I.0..VPV.2000
17:38:08.451 -> 0D 0A 50 50 56 09 30 0D  0A 43 53 09 30 0D 0A 4D  |  ..PPV.0..CS.0..M
17:38:08.451 -> 50 50 54 09 30 0D 0A 4F  52 09 30 78 30 30 30 30  |  PPT.0..OR.0x0000
17:38:08.451 -> 30 30 30 31 0D 0A 45 52  52 09 30 0D 0A 4C 4F 41  |  0001..ERR.0..LOA
17:38:08.451 -> 44 09 4F 46 46 0D 0A 52  65 6C 61 79 09 4F        |  D.OFF..Relay.O
17:38:08.484 -> 46 46 0D 0A 48 31 39 09  31 38 36 30 0D 0A 48 32  |  FF..H19.1860..H2
17:38:08.484 -> 30 09 37 34 0D 0A 48 32  31 09 32 30 38 0D 0A 48  |  0.74..H21.208..H
17:38:08.484 -> 32 32 09 31 34 37 0D 0A  48 32 33 09 35 33 37 0D  |  22.147..H23.537.
17:38:08.484 -> 0A 48 53 44 53 09 31 37  0D 0A 43 68 65 63        |  .HSDS.17..Chec
17:38:08.490 -> 6B 73 75 6D 09 3E                                 |  ksum.>
17:38:09.419 -> 0D 0A 50 49 44 09 30 78  41 30 36 39 0D 0A 46 57  |  ..PID.0xA069..FW
17:38:09.419 -> 09 31 36 34 0D 0A 53 45  52 23 09 48 51 32 33 33  |  .164..SER#.HQ233
17:38:09.419 -> 39 34 4D 39 56 47 0D 0A  56 09 35 32 32 32 30 0D  |  94M9VG..V.52220.
17:38:09.419 -> 0A 49 09 30 0D 0A 56 50  56 09 32 30 30 30        |  .I.0..VPV.2000
17:38:09.452 -> 0D 0A 50 50 56 09 30 0D  0A 43 53 09 30 0D 0A 4D  |  ..PPV.0..CS.0..M
17:38:09.452 -> 50 50 54 09 30 0D 0A 4F  52 09 30 78 30 30 30 30  |  PPT.0..OR.0x0000
17:38:09.452 -> 30 30 30 31 0D 0A 45 52  52 09 30 0D 0A 4C 4F 41  |  0001..ERR.0..LOA
17:38:09.452 -> 44 09 4F 46 46 0D 0A 52  65 6C 61 79 09 4F        |  D.OFF..Relay.O
17:38:09.484 -> 46 46 0D 0A 48 31 39 09  31 38 36 30 0D 0A 48 32  |  FF..H19.1860..H2
17:38:09.484 -> 30 09 37 34 0D 0A 48 32  31 09 32 30 38 0D 0A 48  |  0.74..H21.208..H
17:38:09.484 -> 32 32 09 31 34 37 0D 0A  48 32 33 09 35 33 37 0D  |  22.147..H23.537.
17:38:09.484 -> 0A 48 53 44 53 09 31 37  0D 0A 43 68 65 63        |  .HSDS.17..Chec
17:38:09.490 -> 6B 73 75 6D 09 3E                                 |  ksum.>


17:38:09.452 -> 30 30 30 31 0D 0A 45 52  52 09 30 0D 0A 4C 4F 41  |  0001..ERR.0..LOA
17:38:09.452 -> 44 09 4F 46 46 0D 0A 52  65 6C 61 79 09 4F        |  D.OFF..Relay.O
17:38:09.484 -> 46 46 0D 0A 48 31 39 09  31 38 36 30 0D 0A 48 32  |  FF..H19.1860..H2
17:38:09.484 -> 30 09 37 34 0D 0A 48 32  31 09 32 30 38 0D 0A 48  |  0.74..H21.208..H
17:38:09.484 -> 32 32 09 31 34 37 0D 0A  48 32 33 09 35 33 37 0D  |  22.147..H23.537.
17:38:09.484 -> 0A 48 53 44 53 09 31 37  0D 0A 43 68 65 63        |  .HSDS.17..Chec
17:38:09.490 -> 6B 73 75 6D 09 3E                                 |  ksum.>

If I work out what was happening with the corrupt data I’ll post again.