Well here it is Beta testers and Aficionados,
This is the latest Firmware to be tested if all seems to work then this will be the next Release code.
Note. this firmware will force the unit to do a factory reset if it doesn't prompt a Factory reset manually Reset the unit. New variables that need to be initialized.
Whats New:
-Bug Fixes Major and Minor
-Added New Communication protocol, Twin Mode, Sync mode and PC(Pc needs the protocol to be published, Still working on auto data streaming support)
-Added more Load Modes LVD alarm
-Added Aux port LVD signal High and Low
-Improved power Output on low light conditions
-Saves previously unsaved variables
Manual is also getting a Major revision and undefined parameters explained, look for new Manual out in the Next Coming weeks.
Please Upload code and Please, Please report back with any changes to be made or problems Found
Ok, now moving on to Wind and Clipper code :)
Mario Rodriguez
Hi Mario, just looked at the list of KID FW and also looked at the Classic listing.
I think there is a bit of a loop on /in the links shown for the CLassic, if one trieds to enter the "PLACE HOLDER" it has 3 links showing: http://www.midnitesolar.com/firmwareIndex.php and http://www.midnitesolar.com/firmware.php?firmwareProduct_ID=1
the first will take you back to the MN list of all FW http://www.midnitesolar.com/firmwareIndex.php
However the second takes one back to the page with PLACE HOLDER on it http://www.midnitesolar.com/firmware.php?firmwareProduct_ID=1 rather than to a LIST Oof FW...??
PS and what does the 'PLACE HOLDER' FW do? http://www.midnitesolar.com/na
'cause this is what one gets:
We are sorry you did not find the page or file you were looking for.
It may have been removed or moved to a new location!
thanks...
Mario,
The KID firmware features are looking pretty good.
The feature I am waiting for is the various data that can be made available via the USB port. I seem to remember you mentioned a query and reply method to extract data items such as battery voltage, input voltage etc.. Are you still progressing with this?
This would allow the KID to provide data to a web server :D
dgd
West Branch, I will have the guy in charge of the Website take a look at that and resolve.
DGD, the data query reply is there now but what it is missing is the protocol to be documented and published, I believe thats the plan, But it will not be through the USB port, you have to use the RS232 Master jack and then you can get a USB to RS232 adapter to connect to your computer and then you can write a program for the PC or if you are really good you can get a Serial over Bluetooth and you can create an App to Query the data. But there is no power on the Master or Slave Jack so you will need to provide that for the Bluetooth adapter if you want to go that route.
Anyways, many possibilities but I have to get working on the documentation to make it available.
Mario
Is the RS232 Master Jack the jack that is labeled Stacking Port in the manual ? ( above the battery sensor jack)
That sounds like a challenge to dgd to get some data squeezed out of there before the documentation arrives !
Larry
Quote from: Mario on April 07, 2015, 05:42:51 PM
DGD, the data query reply is there now but what it is missing is the protocol to be documented and published, I believe thats the plan, But it will not be through the USB port, you have to use the RS232 Master jack and then you can get a USB to RS232 adapter to connect to your computer and then you can write a program for the PC or if you are really good you can get a Serial over Bluetooth and you can create an App to Query the data. But there is no power on the Master or Slave Jack so you will need to provide that for the Bluetooth adapter if you want to go that route.
Excellent, rs232 is better for me as my Arduino DUE web server does rs232. All I will need to do is make a simple API
OK, I will (im)patiently wait on the documentation for this and in meantime get a nice KID web page designed :)
dgd
Another request that Mario worked on but did not mention, the temperatures now display in the automatic data scroll.
I have been waiting for the data for quite some time as well. My plan is a little different than dgd's. I am planning on polling the data with my Beaglebone, wrapping it with SNMP and then am able to query it and graph it with Cacti. Cacti uses rrd to do the data store, so you can drill into any data from the past year. I have an rj-12 cable on order, and cannot wait to play.
Will probably upgrade my firmware tonight to the latest if anyone wants to see the new firmware before trying, I will add the link to my signature.
Mario, can you share the pinout for the port?
Jim
Quoteand in meantime get a nice KID web page designed :)
Based on Calvin, of Calvin and Hobbes? see last frame...
http://assets.amuniversal.com/61224fa0a5370132cc37005056a9545d
v 1791 loaded and ready for action. I noticed the temperature shows up in the automatic scroll, which is great, but in the manual scroll from the buttons, it does not show, you have to go into the settings temps menu to see them manually. I am okay with this, but thought I would point it out.
Thanks Mario!
Jim
Quote from: Mario on April 07, 2015, 04:45:46 PM
....Note. this firmware will force the unit to do a factory reset if it doesn't prompt a Factory reset manually Reset the unit. New variables that need to be initialized.....
Is this for Classic or Kid (or both?)
Will storing the settings via the Local App, be able to restore them, or is this update too different to reload the old settings ?
Quote from: mike90045 on April 07, 2015, 10:45:13 PM
Is this for Classic or Kid (or both?)
Will storing the settings via the Local App, be able to restore them, or is this update too different to reload the old settings ?
This is for the KID, so no Local App as the KID doesn't have any built in ethernet capabilities. Jot down your settings before flashing if you don't remember them all.
Quote from: Westbranch on April 07, 2015, 05:18:15 PM
Hi Mario, just looked at the list of KID FW and also looked at the Classic listing.
I think there is a bit of a loop on /in the links shown for the CLassic, if one trieds to enter the "PLACE HOLDER" it has 3 links showing: http://www.midnitesolar.com/firmwareIndex.php and http://www.midnitesolar.com/firmware.php?firmwareProduct_ID=1
the first will take you back to the MN list of all FW http://www.midnitesolar.com/firmwareIndex.php
However the second takes one back to the page with PLACE HOLDER on it http://www.midnitesolar.com/firmware.php?firmwareProduct_ID=1 rather than to a LIST Oof FW...??
PS and what does the 'PLACE HOLDER' FW do? http://www.midnitesolar.com/na
'cause this is what one gets:
We are sorry you did not find the page or file you were looking for.
It may have been removed or moved to a new location!
thanks...
I kept the place holder there so it is easier to add a Beta version when I need to sorry for the confusion and I have removed it so as not to cause any issues
Hi, I have down loaded new version # 1791 and did a factory reset. However I don't see any different in the status screens. Everything looks like the previous software ver. 1742. Is there something I need to turn on? When the Kid boots up it displays ver, 1791.
Kent
Edit: maybe I got ahead of myself, I now see the CPU and FET temps. I now remember where I read that they only show up in auto scroll and not in the manual scroll. My mistake.
If you turn auto-scroll on, which is the default I believe, then when the screens start changing automatically, you will see the temperature screen. It will have CPU temp, FET tmp, and if you have the MNBTS, you will see battery temp as well. This screen was not in the previous firmware versions, and was only accessible manually by going to the temperature menu. Other areas mentioned by Mario include the changes to the communications menu where follow me wording is changed along with the ability to now select "PC". This is serial data that will be available. There are some other changes as well, and some behind the scenes bug fixes such as the one I was having where low light conditions were not finding the maximum power point correctly. I have not checked the latest firmware, but the battery temp modification percentage should also be saved between restarts as well now.
If you are not seeing the obvious menu changes and scrolling data, I would recommend re-flashing the KID, and make sure it does a factory reset (prompting you for the initial setup parameters of your battery).
Jim
I am getting a bad firmware message on both of my kids when plugged in a windows 8.1 machine. Power cycles will not get them out of the firmware update stating bad firmware. What up? Same machine I've always used to update them. Did Gates send out some incompatible updates? :o
How do I get them back online? :-\
Update: It was idiot operator (me that is :-[) error. Midnite tech support is outstanding!
Quote from: Mario on April 07, 2015, 05:42:51 PM
...
Anyways, many possibilities but I have to get working on the documentation to make it available.
Apart from the data output from the rs232 port are there any input commands available?
I'm thinking of an input to force different charge States, especially FLOAT (so that follow-me can be implemented between two or more KIDS or Classics and KIDS), also to turn off battery charging.
Dgd
Just did the 1791 update - all went okay - got all the setpoints re-entered. Finally went to Tech screen to cofirm new firmware version - and accidentally hit enter on Firmware Update ! Darn - didn't seem like any way to back out of it since I still had USB plug in laptop. So had to reload firmware 1791 though it went fast and all my setpoints stuck in this time so maybe it knew there was no update needed.
Larry
Geez - doesn't seem fair - USA about the only country in the world that uses Fahrenheit temperatures and Kid is made in USA and darn - only Centigrade temps on the scroll ! Yeah I know don't want to confuse the rest of the world .
Some days I think I like the Fahrenheit temperature system, with it's tighter graduations between increments. Other days I wish we would just get over it and go metric so the math actually makes sense. Anymore I know how to use both and can convert between them in my head, but if I didn't have to, what else could I be doing with those brain cells? Is it pride that prevents us from teaching the metric system as primary measurement? Anyway, off topic.
Sure do like 1791. My cable should be here tomorrow... will start seeing what that serial port has to offer.
Jim
High temperatures in metric units makes sense to me and are are easier to work with (melting metals). Lower temperatures I have to think about and remember to add 32.. Sure would be nice to choose between F and C which I suggested on the first "Report Card" thread. Kind of like converting between Torr, Microns, Bar, and PSI or Pa. Kind of a pain but there are apps to assist. Option to choose would be great if there is a wish list.
Another one would be a key stroke or option to abort the FW update. I was dead in the water earlier today until Jim told me about the windows update.
Quote from: xsnrg on April 11, 2015, 12:13:07 AM
Sure do like 1791. My cable should be here tomorrow... will start seeing what that serial port has to offer.
Jim
What cable ?
RJ12 cable to plug into the KID master port. The plan right now is to do a custom connector on the other end that will mate to the serial port on my beaglebone.
Okay - RJ 11 is like 6 pin telephone cord - I was lucky to find a real long one of those to remote the MNGP display from my Classic from my shed into the house. I will have to scrounge around and see if I have another one so I can make a cable for my Kid too. Will those serial signals need to be converted for the Beaglebone or can you run them in direct ?
Larry
Quote from: ClassicCrazy on April 11, 2015, 05:26:13 PM
Okay - RJ 11 is like 6 pin telephone cord - I was lucky to find a real long one of those to remote the MNGP display from my Classic from my shed into the house. I will have to scrounge around and see if I have another one so I can make a cable for my Kid too. Will those serial signals need to be converted for the Beaglebone or can you run them in direct ?
Larry
Has the BBB actually got a serial rs232 port? I didn't think it had, at least the one I borrowed only had the USB serial port.
So to connect you will need a USB to rs232 converter.
Of if the BBB has serial ports brought out to expansion pins then you will need a TTL <> rs232 converter but you will also need to check that the
expansion pins are not 3.3v max (as opposed to 5v) otherwise you will need to ensure your converter works with 3.3v TTL
Connecting up a converter with 5v TTL will definitely damage the BBB if its using 3.3v expansion pins.
There are probably good solutions and explanations concerning connecting rs232 in the BBB forums
dgd
Larry,,
There is an rs232 Cape available for the bbb. You would have to connect the KID to that Cape.
Lots of info in bbb forums ;)
Dgd
Quote from: dgd on April 12, 2015, 01:05:42 AM
Larry,,
There is an rs232 Cape available for the bbb. You would have to connect the KID to that Cape.
Lots of info in bbb forums ;)
Dgd
Surely, here is the micro cape I was looking at: http://www.logicsupply.com/components/beaglebone/capes/cbb-ttl-232/ (http://www.logicsupply.com/components/beaglebone/capes/cbb-ttl-232/)
The TTL level differences are known from when I did the research and built my voltage divider circuit. All of your comments are correct though.
The cable did show up yesterday, but still need the rj-12 (6 pin) pin-out from the KID. Easier to get it from those that know than try to follow the traces.
Mario,
Can we have an example of how to get the battery voltage from the rs232 serial port?
I know you want to fully document this in a manual update but what about some clues posted here?
Dgd
So I'm assuming that "Twin" mode has replaced "Bully" mode. Twin 2 generates more heat, 5 to 10 °C more temperature with screen saying less output than the master. The master also programs battery output down to 15 amps and defaults to O&P solar when you connect them. Is this normal? Seems to work well. Outputs don't agree with each other and sometimes they are 80 to 100 watts different when above 250 watts output (12 volts), twin 2 always lower output and running hottest temp wise. Is this normal?
Quote from: dgd on April 13, 2015, 06:09:44 AM
Mario,
Can we have an example of how to get the battery voltage from the rs232 serial port?
I know you want to fully document this in a manual update but what about some clues posted here?
Dgd
please :D
I will try to do a quick write up to poll some data from the kid serial port, but if you want to see the data out of the kid hook it up to the master jack on the kid and set the mode to Sync that will periodically spit data,
Every packet is 4 bytes long.
Mario
Quote from: Mario on April 22, 2015, 12:47:20 PM
I will try to do a quick write up to poll some data from the kid serial port, but if you want to see the data out of the kid hook it up to the master jack on the kid and set the mode to Sync that will periodically spit data,
Every packet is 4 bytes long.
Mario
What is the baud rate of the data ? And what is the pinout for serial connections ?
Thanks
Larry
Master Jack Pinout:
P3= TX
P4= RX
P5= GND
UART_BAUD 57600
Mario
Oh yeah! Time to play.
Very Happy :)
Yesterday, I try connection between the raspberry pi and KID, using a python script. Put the KID communication mode at SYNC.
I used a PL2303 Serial Port, usb to serial port.
This is the output of what the raspberry pi receive every 10 seconds, 9 packets of 4 bytes (don't know what they means...)
9a:bf:22:00
f3:f7:fb:00
9b:d9:7f:36
fb:00:cd:cd
3f:34:9b:ff
00:33:e7:f9
00:9d:f7:7f
35:0f:f9:00
99:0f:f9:00
I join the python script.
Jean-Francois
I haven't had the chance to hook the port up yet unfortunately, but would be curious if you could upload a large section of data, say a 10 minute file or such?
Thanks
Jim
Quote from: ClassicCrazy on April 10, 2015, 11:52:36 PM
Geez - doesn't seem fair - USA about the only country in the world that uses Fahrenheit temperatures and Kid is made in USA and darn - only Centigrade temps on the scroll ! Yeah I know don't want to confuse the rest of the world .
Time to understand you're BEHIND the curve , catch up !!
Edit : Bad spelling , Thanks for the reminder XS
"you're", but I agree actually. ;)
The metric system makes the math so much easier.. so much so that you can do nearly anything in your head. I grew up on the old system as well. They tried to teach us both, but when you needed it a wrench, it was always 9/16" I am acclimating to the metric system by forcing myself to use it more. F to C is probably the hardest transition though. Dammit, water freezes at 32. Sigh.
I'd rather have the bits and cpu cycles of the KID give me more info on the serial port than convert C to F Once we get the data off, we can covert to Joules, degrees K, HP, and such. I have about 1 HP of panels :)
Jim
Hello! I reformat the output of the script to be more readable and add time. The interval is not 10 seconds but 12!
Here is the new script and an output file.
Jean-Francois
Mario,
It's been a month since you released 1791 so just a gentle reminder about the documentation for the serial port data. I can see the data dump as others have detailed but it's not obvious how it's encoded
Just some clues posted here would be a really good start.
Web server for KID ready to go :P
Dgd
Quote from: caribou on April 24, 2015, 10:32:25 AM
9a:bf:22:00
f3:f7:fb:00
9b:d9:7f:36
fb:00:cd:cd
3f:34:9b:ff
00:33:e7:f9
00:9d:f7:7f
35:0f:f9:00
99:0f:f9:00
Mario,
I have manipulated this data, done binary analysis, bit shifted in all directions, anded and ored with all sorts of bit patterns AND still have not managed to extract what looks likes meaningful data items from it.
Is it really just gibberish?
If not please please please just explain what it is.
All I would like is some way to get the battery voltage, wbjr amps and the usual useful data items from the KID.
Can you help?
dgd
Hello here is a quick and dirty explanation on what that data means;
-Every package is and must be consisted of 4 bytes.
-the first 2 bits tell the package type, so there are 4 possible package types
-#define PK_TYPE_Restricted 0X00 /// 00 we should never get this in the first 2 bits....
-#define PK_TYPE_Restricted 0X01 /// 01 Restricted
-#define PK_TYPE_SET 0X02 /// 10 This type comes from the kid as a reply to the PC or to the master Kid
-#define PK_TYPE_GET 0X03 /// 11 Master Kid or PC is asking for a Variable
----- Here is how the Package gets structured:
Type SET: Set is used mostly by the slave to respond to the master or PC to be able to respond to a GET PK.
there is an enum with a list of variables it can get send there are 6 bits on the 4 byte pk that will be used to
define only the variables to send and receive.
Structure of a Set Pack
PK Type What2Set Data (Required) XOR
10 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Set: Variable from the enum to be able to interpret the data
Data: Actual data 16 bits
Type GET: Get is mostly used by the Master or PC to ask the slave for a variable.
Any Get pk will be responded by a set PK.
Every Pk has to consist on the following:
PK Type What2Get Data (Optional) XOR
11 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Get: Variable from the enum to be able to interpret the data
And here is the Enum:
/* the SET list*/
typedef enum{ // there are 6 bits for this list.
null = 0, /// Not Used
special_key = 3, /// Special key for different Comm modes.
COMM_MODE = 5, /// Not for PC Comm Mode for internal use
COMM_status, /// Not for PC. Comm Status
COMM_RAWiBATT, /// Not for PC. to be able to get the offset of the slave unit
COMM_iBATT , /// Not for PC
COMM_vPV, /// PV Voltage displayed on the kid
COMM_vBATT, /// Battery voltage displayed on the kid
COMM_fetTEMP, /// Internal FET temperature
COMM_loadSTATE, /// Load state On, off, iddle, overcurrent
COMM_KWH, /// displayed KWH daily
COMM_PWMERROR, /// Not for PC Twin mode Only
COMM_wimpf, /// Not for PC Twin mode Only
COMM_batteryStage, /// Battery charge stage Absorb, Bulk, Float, EQ
COMM_batt_setpoint, /// for test Do not use, invalid parameter
COMM_absorbV, /// Absorb battery voltage setpoint value
COMM_floatV, /// Float battery voltage setpoint value
COMM_eqV, /// Eq battery voltage setpoint value
COMM_absorbT, /// Absorb battery time setpoint in minutes
COMM_batteryTemp, /// Battery Temperature as read from the BTS
COMM_TempCompV, /// Battery temperature compensation setpoint in mV
Comm_SystemSet, /// For Twin mode. set the other unit system
Comm_BattNominal, /// battery nominal 12, 24, 36,48 v
Comm_EqT, /// Eq battery time setpoint in minutes
}comm_var;
More Variables could be added to the list if required. Let me know so I can update the list of variables supported.
Now for the data you are seeing. The data you are seeing is of a SET type: here is what the Master is sending:
switch(master_var_send){
handle_set_send(COMM_batteryTemp, dispavg_batt_temp);
handle_set_send(COMM_batteryStage, BattChargeStage);
handle_set_send(COMM_absorbV, absorbV);
handle_set_send(COMM_floatV, floatV);
handle_set_send(COMM_eqV, eqV);
handle_set_send(COMM_TempCompV, BattTempCompOrigValue);
handle_set_send(Comm_BattNominal, battery_nominal);
handle_set_send(COMM_vBATT, dispavgVbatt);
handle_set_send(COMM_absorbT, absorbT);
handle_set_send(Comm_EqT, eqT);
The first variable in the function is from the Enum and the second one is the actual data.
I hope this helps a little, Maybe this needs to go in a new tread.
Mario Rodriguez
Thanks Mario.
Some WBjr data would be nice when you get time
WBjr amps, remote temp, SOC%, AH net, used and remaining, ending amps and anything else you can think of
Also KID serial #, software release, KID name(if it exists)
dgd
Hello Mario!
Thanks for the informations!
I'll try to match the data that I receive from the kid with what I suppose to receive...
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
Quote from: Mario on June 05, 2015, 06:24:33 PM
Hello here is a quick and dirty explanation on what that data means;
-Every package is and must be consisted of 4 bytes.
-the first 2 bits tell the package type, so there are 4 possible package types
-#define PK_TYPE_Restricted 0X00 /// 00 we should never get this in the first 2 bits....
-#define PK_TYPE_Restricted 0X01 /// 01 Restricted
-#define PK_TYPE_SET 0X02 /// 10 This type comes from the kid as a reply to the PC or to the master Kid
-#define PK_TYPE_GET 0X03 /// 11 Master Kid or PC is asking for a Variable
----- Here is how the Package gets structured:
Type SET: Set is used mostly by the slave to respond to the master or PC to be able to respond to a GET PK.
there is an enum with a list of variables it can get send there are 6 bits on the 4 byte pk that will be used to
define only the variables to send and receive.
Structure of a Set Pack
PK Type What2Set Data (Required) XOR
10 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Set: Variable from the enum to be able to interpret the data
Data: Actual data 16 bits
Type GET: Get is mostly used by the Master or PC to ask the slave for a variable.
Any Get pk will be responded by a set PK.
Every Pk has to consist on the following:
PK Type What2Get Data (Optional) XOR
11 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Get: Variable from the enum to be able to interpret the data
And here is the Enum:
/* the SET list*/
typedef enum{ // there are 6 bits for this list.
null = 0, /// Not Used
special_key = 3, /// Special key for different Comm modes.
COMM_MODE = 5, /// Not for PC Comm Mode for internal use
COMM_status, /// Not for PC. Comm Status
COMM_RAWiBATT, /// Not for PC. to be able to get the offset of the slave unit
COMM_iBATT , /// Not for PC
COMM_vPV, /// PV Voltage displayed on the kid
COMM_vBATT, /// Battery voltage displayed on the kid
COMM_fetTEMP, /// Internal FET temperature
COMM_loadSTATE, /// Load state On, off, iddle, overcurrent
COMM_KWH, /// displayed KWH daily
COMM_PWMERROR, /// Not for PC Twin mode Only
COMM_wimpf, /// Not for PC Twin mode Only
COMM_batteryStage, /// Battery charge stage Absorb, Bulk, Float, EQ
COMM_batt_setpoint, /// for test Do not use, invalid parameter
COMM_absorbV, /// Absorb battery voltage setpoint value
COMM_floatV, /// Float battery voltage setpoint value
COMM_eqV, /// Eq battery voltage setpoint value
COMM_absorbT, /// Absorb battery time setpoint in minutes
COMM_batteryTemp, /// Battery Temperature as read from the BTS
COMM_TempCompV, /// Battery temperature compensation setpoint in mV
Comm_SystemSet, /// For Twin mode. set the other unit system
Comm_BattNominal, /// battery nominal 12, 24, 36,48 v
Comm_EqT, /// Eq battery time setpoint in minutes
}comm_var;
More Variables could be added to the list if required. Let me know so I can update the list of variables supported.
Now for the data you are seeing. The data you are seeing is of a SET type: here is what the Master is sending:
switch(master_var_send){
handle_set_send(COMM_batteryTemp, dispavg_batt_temp);
handle_set_send(COMM_batteryStage, BattChargeStage);
handle_set_send(COMM_absorbV, absorbV);
handle_set_send(COMM_floatV, floatV);
handle_set_send(COMM_eqV, eqV);
handle_set_send(COMM_TempCompV, BattTempCompOrigValue);
handle_set_send(Comm_BattNominal, battery_nominal);
handle_set_send(COMM_vBATT, dispavgVbatt);
handle_set_send(COMM_absorbT, absorbT);
handle_set_send(Comm_EqT, eqT);
The first variable in the function is from the Enum and the second one is the actual data.
I hope this helps a little, Maybe this needs to go in a new tread.
Mario Rodriguez
Ok, everything is ok! It was my serial to usb adapter that was not working properly.
Now, I receive correctly every packets.
:-)
Jean-Francois
Quote from: caribou on June 07, 2015, 10:05:48 PM
Hello Mario!
Thanks for the informations!
I'll try to match the data that I receive from the kid with what I suppose to receive...
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
Quote from: Mario on June 05, 2015, 06:24:33 PM
Hello here is a quick and dirty explanation on what that data means;
-Every package is and must be consisted of 4 bytes.
-the first 2 bits tell the package type, so there are 4 possible package types
-#define PK_TYPE_Restricted 0X00 /// 00 we should never get this in the first 2 bits....
-#define PK_TYPE_Restricted 0X01 /// 01 Restricted
-#define PK_TYPE_SET 0X02 /// 10 This type comes from the kid as a reply to the PC or to the master Kid
-#define PK_TYPE_GET 0X03 /// 11 Master Kid or PC is asking for a Variable
----- Here is how the Package gets structured:
Type SET: Set is used mostly by the slave to respond to the master or PC to be able to respond to a GET PK.
there is an enum with a list of variables it can get send there are 6 bits on the 4 byte pk that will be used to
define only the variables to send and receive.
Structure of a Set Pack
PK Type What2Set Data (Required) XOR
10 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Set: Variable from the enum to be able to interpret the data
Data: Actual data 16 bits
Type GET: Get is mostly used by the Master or PC to ask the slave for a variable.
Any Get pk will be responded by a set PK.
Every Pk has to consist on the following:
PK Type What2Get Data (Optional) XOR
11 000000 00000000 00000000 00000010
PK Type: This is the global pk type only 4 variations.
What2Get: Variable from the enum to be able to interpret the data
And here is the Enum:
/* the SET list*/
typedef enum{ // there are 6 bits for this list.
null = 0, /// Not Used
special_key = 3, /// Special key for different Comm modes.
COMM_MODE = 5, /// Not for PC Comm Mode for internal use
COMM_status, /// Not for PC. Comm Status
COMM_RAWiBATT, /// Not for PC. to be able to get the offset of the slave unit
COMM_iBATT , /// Not for PC
COMM_vPV, /// PV Voltage displayed on the kid
COMM_vBATT, /// Battery voltage displayed on the kid
COMM_fetTEMP, /// Internal FET temperature
COMM_loadSTATE, /// Load state On, off, iddle, overcurrent
COMM_KWH, /// displayed KWH daily
COMM_PWMERROR, /// Not for PC Twin mode Only
COMM_wimpf, /// Not for PC Twin mode Only
COMM_batteryStage, /// Battery charge stage Absorb, Bulk, Float, EQ
COMM_batt_setpoint, /// for test Do not use, invalid parameter
COMM_absorbV, /// Absorb battery voltage setpoint value
COMM_floatV, /// Float battery voltage setpoint value
COMM_eqV, /// Eq battery voltage setpoint value
COMM_absorbT, /// Absorb battery time setpoint in minutes
COMM_batteryTemp, /// Battery Temperature as read from the BTS
COMM_TempCompV, /// Battery temperature compensation setpoint in mV
Comm_SystemSet, /// For Twin mode. set the other unit system
Comm_BattNominal, /// battery nominal 12, 24, 36,48 v
Comm_EqT, /// Eq battery time setpoint in minutes
}comm_var;
More Variables could be added to the list if required. Let me know so I can update the list of variables supported.
Now for the data you are seeing. The data you are seeing is of a SET type: here is what the Master is sending:
switch(master_var_send){
handle_set_send(COMM_batteryTemp, dispavg_batt_temp);
handle_set_send(COMM_batteryStage, BattChargeStage);
handle_set_send(COMM_absorbV, absorbV);
handle_set_send(COMM_floatV, floatV);
handle_set_send(COMM_eqV, eqV);
handle_set_send(COMM_TempCompV, BattTempCompOrigValue);
handle_set_send(Comm_BattNominal, battery_nominal);
handle_set_send(COMM_vBATT, dispavgVbatt);
handle_set_send(COMM_absorbT, absorbT);
handle_set_send(Comm_EqT, eqT);
The first variable in the function is from the Enum and the second one is the actual data.
I hope this helps a little, Maybe this needs to go in a new tread.
Mario Rodriguez
Quote
And here is the Enum:
/* the SET list*/
typedef enum{ // there are 6 bits for this list.
null = 0, /// Not Used
special_key = 3, /// Special key for different Comm modes.
COMM_MODE = 5, /// Not for PC Comm Mode for internal use
COMM_status, /// Not for PC. Comm Status
COMM_RAWiBATT, /// Not for PC. to be able to get the offset of the slave unit
COMM_iBATT , /// Not for PC
COMM_vPV, /// PV Voltage displayed on the kid
COMM_vBATT, /// Battery voltage displayed on the kid
COMM_fetTEMP, /// Internal FET temperature
COMM_loadSTATE, /// Load state On, off, iddle, overcurrent
COMM_KWH, /// displayed KWH daily
COMM_PWMERROR, /// Not for PC Twin mode Only
COMM_wimpf, /// Not for PC Twin mode Only
COMM_batteryStage, /// Battery charge stage Absorb, Bulk, Float, EQ
COMM_batt_setpoint, /// for test Do not use, invalid parameter
COMM_absorbV, /// Absorb battery voltage setpoint value
COMM_floatV, /// Float battery voltage setpoint value
COMM_eqV, /// Eq battery voltage setpoint value
COMM_absorbT, /// Absorb battery time setpoint in minutes
COMM_batteryTemp, /// Battery Temperature as read from the BTS
COMM_TempCompV, /// Battery temperature compensation setpoint in mV
Comm_SystemSet, /// For Twin mode. set the other unit system
Comm_BattNominal, /// battery nominal 12, 24, 36,48 v
Comm_EqT, /// Eq battery time setpoint in minutes
}comm_var;
More Variables could be added to the list if required. Let me know so I can update the list of variables supported.
Mario,
Have you extended this enum list yet?
I assume iBATT is battery current and the 'not for PC' part is wrong :)
I would like to see the following added
COMM_watts /// watts power being output
COMM_wbjrA, /// WBjr amps, in one tenth amps as signed int, divide by 10 to get amps
(and do the same with other amp readings such as iBATT and loadamps)
COMM_soc, /// battery SOC% (in one byte, maybe use other for charge efficiency)
COMM_absTimeleft // absorb time down counter
COMM_floatTime // total float time up counter
COMM_remoteTemp, /// WBjr remote temperature
COMM_Battahrem, /// Battery Amp Hours remaining
COMM_Battahnet, /// Battery Amp hours nett
COMM_Battahcapacity // battery capacity
COMM_Battefficiency // battery charge efficiency
COMM_Kidserialno, /// Kid serial number
COMM_KidFWvers /// Kid firmware version
COMM_Kidname1 /// user defined name for KID, first 2 chars
COMM_Kidname2 /// User defined name for KID, second 2 chars
COMM_Kidname3 /// user defined name for KID, third 2 chars
COMM_Kidname4 /// User defined name for KID, fourth 2 chars
COMM_Loadamps /// Load current output
and more that you have already probably added.
Since there is no RTC in the KID but there appears to be a timer then some way to set this with data from computer would be nice/interesting. Is there any timer info available?
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
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
Thanks Mario, I will await further firmware releases.
dgd
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
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
Question: Is the data being sent from the Kid via rj11 in the Modbus Protocol or some other Midnite solar specific format?
Quote from: esol on March 30, 2016, 02:56:48 PM
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.
Quote from: dgd on February 18, 2016, 08:11:16 PM
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 :D
Quote from: caribou on June 07, 2015, 10:05:48 PM
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.
Quote from: esol on April 05, 2016, 01:24:33 PM
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?
If the firmware is what shows up when the kid first boots up, I believe it is v. 1811.
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?
Quote from: esol on April 05, 2016, 02:56:07 PM
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".
what should I use to connect the kid to PC
Quote from: lysningen on July 27, 2016, 04:27:30 PM
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