Data logging

Yes it's TTL levels.  Are you getting anything out of the MSB TX pin?

Do you the baud rate set up?  

Not to my knowledge.  I was able to whip up some code for an MCU to read from it with just the info discussed here.

Assuming you have UART polarity correct (active low, 9600 baud, no parity, 1 stop bit--standard behavior)--you need to send a full packet before it will respond.

As per my earlier post, the "request data" packet is as follows:

[0xAA] [0x55] [0x00 0x00 0x00] [checksum] -> "Read Status"

Without a proper "checksum", the MSB will not respond.  As the "checksum" is the simple sum of all the bytes AFTER the 0xAA "device ID" byte, the checksum for a read command will be 0x55.

So a full "read" packet should be:

[0xAA] [0x55] [0x00] [0x00] [0x00] [0x55]

and the MSB should respond within 300mS

It is worth noting that all of the testing in this thread was on a v119 MSB...I don't know how the v118 would behave.  Especially worth noting that the "Wifi dongle" I have is marked "REV:A", and the picture you linked is "REV:B1".  Unfortunately, as nobody here is an official MSB rep (and an official rep would refuse to talk!), it's kinda difficult to say exactly what to do...especially as I don't have an MSB with v118.

Another thing to note: I don't know what exactly you're sending, but the notation provided above is BINARY DATA, not plain text.  [0xAA] = a binary byte that translates to a decimal 170 = ASCII [ ª ].  The MSB will also respond with binary data, not plain text.

The entire "request status packet" is 6 bytes, including the checksum.  You likely won't be able to do this with a regular "terminal" program--most of them work with plain text, not binary data.

Hi Guys,
Managed to get things to work. got hold of the wifi module, checked the packets it was sending and so on and after a days worth of snooping ended up full circle with sending the read status packet and getting a reply, exactly as it was mentioned. The other fact I learned is that the cable I initially used had a bad tx wire 🤦‍♂️. I am now using Blynk to view and log all the data. @sid-genetry-solar  Your guide was extremely helpful. Thank you very much!

I'm glad you got it working!

Just to be clear...  You got the data logging working with a V118?   I blew out my 40A a while ago (fried the controller, I think) and I want to get a replacement.  If I can get by with a V118 and save myself a couple bucks and still be able to log, then great!

Managed to get things to work. got hold of the wifi module, checked the packets it was sending and so on and after a days worth of snooping ended up full circle with sending the read status packet and getting a reply, exactly as it was mentioned. The other fact I learned is that the cable I initially used had a bad tx wire 🤦‍♂️. I am now using Blynk to view and log all the data.

You are  very smart  and would  be making  a lot of money if you live in the USA  

Yep. This is the V118; USB version though. It comes with a mini USB output port for which they sell a separate Wifi box.

Yeah, just go ahead and reuse a very specific connector for a generic purpose 😉.  As you already noticed earlier on, that "USB" port has RS-232 data on it.  Not exactly "USB" 😉.

Oh that's something!! Jeez!

I have a busted v119 that I'll just steal the wifi from and then hack. So I'll be ripping open the unit anyway. I'll have to see if mine has the*USB* port though!😂

I just got my V118 40A version.  I tried using my V119 wifi module from my  busted MSB one and I'm not getting any response! 😞

I wonder if the V118 firmware can't do the handshake and cause the wifi to ask for the status...

I don't see the wifi send the AA 55..

I do get one initial AA BB response from the MSB after power on..  But nothing after that.

Maybe I'll hook up a ucontroller and send the request command tomorrow instead of hooking up the old wifi module...

jim

Huh..  I thought I replied to this already..  Oh well..  I did hook up the ucontroller and it responds!!  Yeah!!

I'm back in business! 

Adding to the protocol...

To turn the  MSB on and off...

To turn the MSB on send:

      write_byte(0xAA);
      write_byte(0xCC);
      write_byte(0x02);
      write_byte(0x00);
      write_byte(0x00);
      write_byte(0xCE);

The response from the turn on command is:

0xaa, 0xdd,  0x0, 0x0, 0x0, 0xdd

To turn the MSB off send:

      write_byte(0xAA);
      write_byte(0xCC);
      write_byte(0x01);
      write_byte(0x02);
      write_byte(0x00);
      write_byte(0xCF);

The response from the turn off command is

0xaa, 0xdd,  0x1, 0x0, 0x0, 0xde

Not sure why some of these values are what they are..  But they work.. (the last byte is the checksum again)
The last byte is the check byte.

When off the mode is 0x0.

Jim

@<a data-ipshover="" data-ipshover-target="/profile/164-amjednizam/?do=hovercard&referrer=https%253A%252F%252Fforums.genetrysolar.com%252Ftopic%252F26-data-logging%252Fpage%252F2%252F" href="/profile/164-amjednizam/" rel="" style="background-color:transparent;color:inherit;" title="Go to amjednizam's profile">amjednizam Could you please hare the connecting diagram of mini usb and code if possible ? I also have V118 with mini usb port.

your help greatly appreciated.

Kolitha.

While we wait for proven input from @amjednizam, I can try to offer a tad of guessing/help....

I obviously don't have one of these units (at least as far as I know!) with the "USB" port on them.

But looking at the picture provided by @amjednizam, I can take a bit of a guess:

<fileStore.core_Attachment>/monthly_2022_09/image.png.3f6e1b919f4e9281b49983facc2a0ffe.png

I only see 3 pins connected--but that doesn't mean the others aren't.

My guess is that the leftmost lead is going to be ground.  (You can verify this by continuity checking to the battery negative terminal.)

The next 2 likely will be RX and TX.  I have no idea which one is which though--it's a 50/50 chance.

I can't see any further connections beyond that, but I would presume that the rightmost lead should be +5v (to power the MakeSkyBlue WiFi module).

As @amjednizam confirmed, the signals will be TTL level (i.e. not RS-232 serial levels).  They also will not be electrically isolated from battery potential--which can be of critical importance if you're connecting it to another device that's also powered by the same power system (i.e. a typical off-grid power system).  Any significant grounding voltage difference likely will be "quickly electrically resolved" with smoke and blown wires/parts/devices.  Just an FYI!

If you're trying to connect this to a laptop, you'll want a USB-to-serial converter (but NOT a USB->RS-232 converter).  The difference being that a USB->serial converter should be TTL level (0v/5v, usually with a solder/pin header/wires), where a USB->RS-232 converter will usually go to RS-232 level (+9/-9v most common, but can easily be +/-12v...with a DB-9 connector)--in addition to also inverting the signal electrical potentials.

An example of a USB->serial converter would be a board with a CH340, or a CP2102.  I would recommend avoiding any boards based on the FT232 chipset--as 99% of the time you'll end up with a counterfeit fake chip from China--which the official manufacturer FTDI has very kindly ensured that their Windoze drivers will NOT work with.  (They initially started out by updating their Windoze driver to effectively brick the counterfeit chips.  Talk about a problematic Windoze update!  Due to backlash, they backed down a bit--now it just reads out nonsense data, instead of bricking the chip.)