IIRC there's at least one thread of someone doing something similar and IIRC again he made a git repo. I recommend to use the search feature to try to find that thread (I don't have it on hand, sorry)
Yeah...you're right on all counts. Need to slow down a bit on these posts.I think you wanted to say modulo: https://en.wikipedia.org/wiki/Modulo_operation
And if I had to guess it's 65536 instead of 35536.
For the conversions part I can't say anything useful without more details from you (i.e. from what to what you want to convert?, for what purpose?, example?).
46, 44, 35, and 33 are the HEX equivalents of the ASCII characters F, D, 5, and 3 (which also correspond to the '30+' decimal equivalents, as you've pointed out). The protocol employs ASCII characters for pretty much all values. For example, the cell voltage values are provided as 30, 44, 34, 35, which is the the equivalent of 0D45, which can then be converted to the the decimal equivalent of 3397 mV. To do that, I'm taking the original hex numbers (30, 44, 34, 45), converting those to decimal values (48, 68, 52, 53) using the "HEX2DEC" excel function, then converting those to ASCII characters (0, D, 5, 3) using the "CHAR" function. Then I use the "HEX2DEC" function again to convert those values to a string of decimals (3, 3, 9, 7). Does not make any sense to me, but it works...in excel. I'm pretty sure I'm just confusing myself by trying to figure this all out in excel.I don't recognize this method .... but it looks to me like it is 30 plus the hex to decimal value of the of each number.
F=16 , D=14, 5=5, 3=3
30 +16 = 46 30 + 14 = 34 30 + 5=35 30 + 3 = 33
Getting a handle on it? Ha. That's very generous.My ASCII is very old and stale .... sounds like you are getting a handle on it.
I've highlighted the corresponding checksum values from two of the examples in the protocol. Is "FD35" the same - from a UART transmission perspective - as "0x46, 0x44, 0x33, 0x35"? Or do I need to somehow 'parse' FD35 and change it to 46 44 33 35 before transmission?
The protocol employs ASCII characters for pretty much all values.
To do that, I'm taking the original hex numbers (30, 44, 34, 45), converting those to decimal values (48, 68, 52, 53) using the "HEX2DEC" excel function, then converting those to ASCII characters (0, D, 5, 3) using the "CHAR" function. Then I use the "HEX2DEC" function again to convert those values to a string of decimals (3, 3, 9, 7). Does not make any sense to me, but it works...in excel. I'm pretty sure I'm just confusing myself by trying to figure this all out in excel.
Are all communication protocols this complicated?
The inverter is sending the 'get analog values' request. The protocol states that the response to that request includes the "INFOFLAG", which I'm assuming is the same as the "DATAFLAG", which is summarized in the table pasted below. In the response that I've been sending, I've got the flag set to 00010001, which I thought would prompt requests for additional data, but that doesn't seem to be happening (not that I've been able to detect, anyway). Need to play around with that a bit more I think.It sounds like the inverter needs a specific frame/packet to trigger events. I have not reviewed the spec, so its just a guess. It may also just be a specific byte(s) in the frame which triggers the specific behavior.
I don't have any inverter documents, so I'm flying blind on that side of things. I did confirm that without an accurate checksum, the inverter does fault out. That said, I haven't tried sending a response with an inaccurate length checksum value. I'll try that tomorrow. If it doesn't care about that one, would save me some work. Good suggestion.Does the inverter docs specify if it actually checks the checksum? In several cases I have found the checksum is carried over for compatibility, but the receiving device doesn't always implement a check in its software.
which I'm assuming is the same as the "DATAFLAG"