Firmware Revision 1791 Solar

[dgd]

Mario,

I suppose since its a 6 bit field with 2^6 or 64 possible values with 0 to 23 used, that I could just cycle through the values 24 to 63 and see what gets returned, assuming of course you have coded extra data items, wbjr etc, that can be returned.

dgd

[Mario]

DGD, At the moment I am working on the kid firmware, there is only 23 vars at the moment, I  will get what you and others here have requested, on the next firmware release.

Mario

[dgd]

Thanks Mario, I will await further firmware releases.

dgd

[caribou]

Mario,

variable to add :

input state (solar on, solar off)
load state (mode)

and the possibility to set value for it.

Thanks you!

Jean-Francois

[dgd]

Mario,

I know you are working on the next KID firmware release and both caribou and I have made suggestions for further data items to be made available via serial port, but I have some more general questions concerning data availability
Presently data items are made available as integer values {?} in two bytes of a 4 byte data packet
The first byte has a 2 bit code to identify a packet sent or received from KID. the other six bits are a data item identifier, the next two bytes an integer 16bit value and the last byte some sort of xor checksum (or whatever)
I imagine near all data packets sent to the KID (from PC) will not have any data, just the first and last bytes
Only packets (ie replies) from KID to PC will actually contain data.

I don't really understand what the last byte is for, as you previously posted its calculated from xor'ing each pair of bits in all 4 bytes (should the last byte be set to null before doing this on a packer to be sent to KID), countin xor bits  then xor again writing result to last byte of packet
I can get this to work ok and see KID data but why such a seemingly complicated and apparently not really necessary exercise?

With such a simple single byte request and three byte reply data set with READ ONLY from KID then why bother with this xor exercise? I would expect decent data reliabiity/integrity over a metre or two rs232 connection from KID to PC.

Rather than all this single data item requesting what about a single request code that would  simply return an array of values with perhaps an attached CRC. I can't see the array being very large as all necessary data integers should fit into normal serial port ring buffer size. Even if two commands for two arrays, one static data such as names, IDs, serial numbers, nominal battery voltage, voltage setpoints etc.. and the other array for dynamic dat items such as voltages, currents, KWhrs, watts etc..

With a decent 57k6 serial connection and if the KIDs cpu can handle it (which it apparently can)  then the dataset should be available every second or less.  Just perfect for an HTML5 page using AJAX for data display updating.

just some thoughts...

dgd

[esol]

Question: Is the data being sent from the Kid via rj11 in the Modbus Protocol or some other Midnite solar specific format? 

[jamesmc]

Question: Is the data being sent from the Kid via rj11 in the Modbus Protocol or some other Midnite solar specific format?

Refer to the post by Mario earlier in this thread:
http://kb1uas.com/mnsforum/index.php?topic=2427.msg24057#msg24057

I believe it is a midnite specific format, not MODBUS protocol.

[jamesmc]

With such a simple single byte request and three byte reply data set with READ ONLY from KID then why bother with this xor exercise? I would expect decent data reliabiity/integrity over a metre or two rs232 connection from KID to PC.

Until its not decent, and something really bad happens when a 1 was supposed to be 0 

[esol]

Hello Mario!

The first byte received should begin with 0x96 that correspond to COMM_batteryTemp (10 01 0110) the first 2 bits should represent the PK_TYPE_SET.
Here, I receive 0x9A and the rest of byte received do not follow the pattern of bytes that should be send...

The communication setup is BAUDRATE = 57600, CharacterSize = 8 bits, Parity= none, stop bit = 1.

The other thing, I receive 37 bytes whe I should receive 40 bytes...
And finally, the forth byte is it corresponding to a form of checksum?

Thanks,

Jean-François Ng

Hello,  has this issue been resolved?  I am using an arduino nano connected to an adapter I made with the rx, tx and ground wires connected to the nano and I am able to read in data from the kid but I am also recieving  the hex value 0x9A. 

[jamesmc]

Hello,  has this issue been resolved?  I am using an arduino nano connected to an adapter I made with the rx, tx and ground wires connected to the nano and I am able to read in data from the kid but I am also recieving  the hex value 0x9A.

Which firmware version are you running on your KID? 

[esol]

If the firmware is what shows up when the kid first boots up, I believe it is v. 1811.

[esol]

Is there a way I can send a request for the data from the kid using the serial connection? For example, instead of waiting to receive bytes from a data stream and collecting 4 bytes of data at a time in a while loop, is it possible for me to send a set request and receive a response for a specific variable such as comm_battery_temp?

[CDN-VT]

If the firmware is what shows up when the kid first boots up, I believe it is v. 1811.

Correct Sir. "firmware is what shows up when the kid first boots up".

[lysningen]

what should I use to connect the kid to PC

[CDN-VT]

what should I use to connect the kid to PC

USB cable to a mini usb USB A   to a USB Mini

I use a real nice cable that came with my Camcorder .

VT