Newest BETA firmware. 4-21-14

Started by Halfcrazy, April 22, 2014, 07:58:27 AM

Previous topic - Next topic

ClassicCrazy

This morning SOC seemed to be working fine and matching close to what Trimetric said. But I couldn't get Local Status App to  connect - might be because I was playing around with Android Local Status app last night too and mixed it up. I tried going into Net settings and changing back and forth from Static to DHCP but just couldn't get Local Status app on computer or Android to find Classic. Finally I resorted to restarting the Classic by powering off and back on. Local Status app works again - but...........

SOC now went back to flashing on Whizbang screen at 93% where before Classic restart it had been 100% though still in absorb not to ending amps.  So I guess when I restarted it it subtracted what was in NET amps and that is how it got to 93% . Since I am getting close to End Amps I am going to leave it and see if that terminates Absorb and goes to float.

From what has been said I am guessing that when it goes from Absorb to Float that should reset the SOC to 100% and then stop it flashing ?  Guess I will find out.

I have changed one setting after the restart and that is I checked Reset Net Ah on 100% SOC . It seems to me if that had zeroed out  this morning at 100% SOC it wouldn't have gone back to 93% like it just did after the restart. . 
system 1
Classic 150 , 5s3p  Kyocera 135watt , 12s Soneil 2v 540amp lead crystal for 24v pack , Outback 3524 inverter
system 2
 5s 135w Kyocero , 3s3p 270w Kyocera  to Classic 150 ,   8s Kyocera 225w to Hawkes Bay Jakiper 48v 15kwh LiFePO4 , Outback VFX 3648 inverter
system 3
KID / Brat portable

boB

Quote from: ClassicCrazy on May 04, 2014, 11:13:44 PM
The only thing I can think is that after I did the update and VMM reset I only put in one or two settings via MNGP . Then I used Local Status App to program in the correct setpoints and I think I hit Force Absorb or Force Float when doing that. My friend may have done the same thing too. So maybe that messes up the normal cycle .  Might be worth an experiment on your test setup to see if that is what caused it.


AhA !   Forcing a Float from Absorb will NOT stop the flashing and reset SOC to 100% anymore.
It must transfer to Float naturally via Ending Amps or timer OR, of course, holding the left
arrow key and pressing the enter button in the WB Jr.  MORE menu.

Did all of you do a Force Float to try and get it to go to 100 %  ?  If so, that is why the SOC did
not reset to 100% and the display stop flashing.

This will need to go into the manual of course.  If there is enough opposition to this method,
then we can think about changing this back to how it was where it resets to 100% SOC when
forcing a Float on a future firmware revision.
K7IQ 🌛  He/She/Me

ClassicCrazy

Yeah the force float explains why it never reset the first time , but today all I did was reset the power - why did it revert back to flashing that time ?

Anyway it changed over to float , stopped the flashing, and the reset net ah to zero is all good now.

An unrelated topic - it would be nice to have some kind of indication of Classic  if it goes to float via ending amps or time. Is that possible ?  Or a graph of status would do the same thing since could tell that way how long it took to change over - would be a nice feature on mymidnite.
system 1
Classic 150 , 5s3p  Kyocera 135watt , 12s Soneil 2v 540amp lead crystal for 24v pack , Outback 3524 inverter
system 2
 5s 135w Kyocero , 3s3p 270w Kyocera  to Classic 150 ,   8s Kyocera 225w to Hawkes Bay Jakiper 48v 15kwh LiFePO4 , Outback VFX 3648 inverter
system 3
KID / Brat portable

zoneblue

#33
When you reboot the classic the SOC reverts to last saved value, which is usually taken at midnight. Thats a hiccup that is being worked on.

For my money, i think the current regime works, the controller knows best. Let it end absord when its ready, and call it 100%. Thats the value of WBJr.

What im ready for is a system where days between bulk is more dynamic. In the summer, i set days between bulk to 5, and it ran really nicely. It falls down when the 5th day is crap weather, never makes absorb, then keeps on counting, the next day no absorb, when it really should try again. Or only absorb below X% SOC.  Hence its back to daily absorbs for the winter here.

We are over panelled, and it only takes a breif clearing in a long run of bad weather to top up the bank, hence it needs a bit of voltage at those times to do the job quick enough.


6x300W CSUN, ground mount, CL150Lite, 2V/400AhToyo AGM,  Outback VFX3024E, Steca Solarix PL1100
http://www.zoneblue.org/cms/page.php?view=off-grid-solar

boB

If the Classic gets powered off and back on again, it has no idea what has happened during that time and so the SOC% is not believable necessarily.  That is exactly what the flashing/blinking means.  And until then, the main status will not show the SOC%.

The only way the Classic can know that the battery is full, for certain, is for it to naturally go from Absorb to Float.
Or, you can force it to full by that button press in the MORE information screen.

Did you reset the Classic or did it reset on its own ?  Hopefully you powered it down and back up again.  We ~think~ that the WDT resets may be behind us now or at least much better and so I am very interested to hear if there are still un-solicited resets going on.

And, ZB, there will be a Re-Bulk on SOC% in there too, eventually.  That was wanted a LONG time ago.
K7IQ 🌛  He/She/Me

ClassicCrazy

No reset problems Bob - I manually reset the power with the breakers. Not sure why the Local Status App communications locked out - worked after I reset the power but then dropped off again in awhile. Later in the day I tried Local Status App and it connected up normally. Maybe that is some kind of router issue cause I am using an older model D-Link. I have a Linksys with DDWRT in it that I will swap out one of these days.
system 1
Classic 150 , 5s3p  Kyocera 135watt , 12s Soneil 2v 540amp lead crystal for 24v pack , Outback 3524 inverter
system 2
 5s 135w Kyocero , 3s3p 270w Kyocera  to Classic 150 ,   8s Kyocera 225w to Hawkes Bay Jakiper 48v 15kwh LiFePO4 , Outback VFX 3648 inverter
system 3
KID / Brat portable

leeelson

#36
I can't install this firmware using a Linux machine. Here's what I get:

./mnupdate.py  Classic_ALL_1849_150V_4-21-2014.ctl
MidNite Firmware Updater
Copyright MidNite Solar Inc. 2012
Firmware size: 189576 bytes
Waiting for serial device.
<Press Ctrl-C to Cancel> . . . . . . . . . . . . . . .
Sleeping for serial port.
Opening serial port: /dev/ttyACM0
could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

Any ideas?

TomW

#37
Quote from: leeelson on May 17, 2014, 10:25:26 PM
I can't install this firmware using a Linux machine. Here's what I get:

./mnupdate.py  Classic_ALL_1849_150V_4-21-2014.ctl
MidNite Firmware Updater
Copyright MidNite Solar Inc. 2012
Firmware size: 189576 bytes
Waiting for serial device.
<Press Ctrl-C to Cancel> . . . . . . . . . . . . . . .
Sleeping for serial port.
Opening serial port: /dev/ttyACM0
could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

Any ideas?

What does "dmesg" say? It should show the port being connected and disconnected.


Try this as root maybe sometimes it takes root to access a serial port  you got a device not found error so its likely not user permissions.


./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl Classic_ALL_1849_150V_4-21-2014.ctl
[/code/
the -z sleeps awhile before trying to update. Some found it helps.
-r is repeat and -d is the device.

Just a thought.

Tom

Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

TomW

Another thing to "test" the port is, while the Classic is running and the USB is connected, run this command in a terminal:

sudo tail -f /var/log/syslog


Then unplug the cable you should see a line about it being disconnected. Plug it back in and it should show it being plugged in. Something like this:
Quote
May 18 01:28:17 NVAIO kernel: [ 3047.540332] cdc_acm 2-6.4.3:1.0: ttyACM0: USB ACM device
May 18 01:28:17 NVAIO kernel: [ 3047.540701] usbcore: registered new interface driver cdc_acm
May 18 01:28:17 NVAIO kernel: [ 3047.540706] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

If it shows up being plugged in then a simple sudo cat /dev/ttyACM0 should dump information to the terminal. Mostly to test the hardware. If you get data dumped to the terminal you know the port and cabling are good.

Just a bit more info in case you are not fluent with Linux

Tom
Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

leeelson

Quote from: TomW on May 18, 2014, 01:55:49 AM


What does "dmesg" say? It should show the port being connected and disconnected.

Seems to:
[  401.302494] usb 5-1: New USB device found, idVendor=ffff, idProduct=0005
[  401.302510] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  401.302521] usb 5-1: Product: BootLoader Version 1.06
[  401.302530] usb 5-1: Manufacturer: MidNite Solar Classic
[  401.302539] usb 5-1: SerialNumber: DEADC0DE
[  401.307101] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
[  401.307169] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
[  424.740140] usb 5-1: USB disconnect, device number 3


Quote from: TomW on May 18, 2014, 01:55:49 AM
Try this as root maybe sometimes it takes root to access a serial port  you got a device not found error so its likely not user permissions.


./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl Classic_ALL_1849_150V_4-21-2014.ctl
[/code/
the -z sleeps awhile before trying to update. Some found it helps.
-r is repeat and -d is the device.

Just a thought.

Tom



Progress! A new error code:
sudo ./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl Classic_ALL_1849_150V_4-21-2014.ctl
MidNite Firmware Updater
Copyright MidNite Solar Inc. 2012
Firmware size: 189576 bytes
Waiting for serial device.
<Press Ctrl-C to Cancel> . . . . .
Sleeping for serial port.
Opening serial port: /dev/ttyACM0
Sending upload command: uPlDrEMaLLfl
Repeating upload command: uPlDrEMaLLfl
Sleeping for flash erase.
<Uploading Firmware>
Update Failed: No ACK byte received

leeelson

Quote from: TomW on May 18, 2014, 02:32:54 AM
Another thing to "test" the port is, while the Classic is running and the USB is connected, run this command in a terminal:

Then unplug the cable you should see a line about it being disconnected. Plug it back in and it should show it being plugged in. Something like this:

If it shows up being plugged in then a simple sudo cat /dev/ttyACM0 should dump information to the terminal. Mostly to test the hardware. If you get data dumped to the terminal you know the port and cabling are good.

Just a bit more info in case you are not fluent with Linux

Tom

I get:
tail -f /var/log/syslog


May 18 12:03:27 elson-mini modem-manager[687]: <info>  (ttyACM0) opening serial port...
May 18 12:03:33 elson-mini modem-manager[687]: <info>  (ttyACM0) closing serial port...
May 18 12:03:33 elson-mini modem-manager[687]: <info>  (ttyACM0) serial port closed
May 18 12:03:37 elson-mini kernel: [17785.732358] usb 5-1: USB disconnect, device number 9
May 18 12:03:43 elson-mini kernel: [17791.124293] usb 5-1: new full-speed USB device number 10 using uhci_hcd
May 18 12:03:43 elson-mini kernel: [17791.294485] usb 5-1: New USB device found, idVendor=ffff, idProduct=0005
May 18 12:03:43 elson-mini kernel: [17791.294506] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 18 12:03:43 elson-mini kernel: [17791.294520] usb 5-1: Product: BootLoader Version 1.06
May 18 12:03:43 elson-mini kernel: [17791.294533] usb 5-1: Manufacturer: MidNite Solar Classic
May 18 12:03:43 elson-mini kernel: [17791.294545] usb 5-1: SerialNumber: DEADC0DE
May 18 12:03:43 elson-mini kernel: [17791.297914] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
May 18 12:03:43 elson-mini kernel: [17791.297969] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
May 18 12:03:43 elson-mini mtp-probe: checking bus 5, device 10: "/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1"
May 18 12:03:43 elson-mini mtp-probe: bus: 5, device: 10 was not an MTP device
May 18 12:03:43 elson-mini modem-manager[687]: <info>  (ttyACM0) opening serial port...


sudo cat /dev/ttyACM0 seems to work. No errors.

boB


I think I see a problem in the documentation for this python update usage
which has to do with the message sent before the code is sent to the
Classic and/or the MNGP/Remote.   I think that the -m message   is
missing for the Classic itself from that readme.txt file.

Just in case this eventually works,

The line....

sudo ./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl Classic_ALL_1849_150V_4-21-2014.ctl

-m uPlDrEMaLLfl   is the  message sent to tell the Classic to forward the code onto the Remote.
This will be repeated (-r)  for the MNGP/Remote to read and then erase its flash...

Then,
Classic_ALL_1849_150V_4-21-2014.ctl

is the code for the Classic, not the MNGP.   That line will want to be replaced with...

MNGP_ALL_1821_4-15-2014.rem

which is the code destined for the Remote.   If you were to update the MNGP with the
Classic code, it would have to be re-programmed with the MNGP code.

There is another message that tells the Classic to send the code for it which  is...

-m uPlDcLSaLLfl

and that option appears to be missing from the documentation so you should change the
first -m  message to this...

sudo ./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDcLSaLLfl Classic_ALL_1849_150V_4-21-2014.ctl

If you haven't yet updated the Classic itself, try that.

There was also some different info from MidNite Mike for Linux or Mac OS X and I'll check on
that again tomorrow (Monday)

boB
K7IQ 🌛  He/She/Me

leeelson

Quote from: boB on May 18, 2014, 08:30:10 PM

I think I see a problem in the documentation for this python update usage
which has to do with the message sent before the code is sent to the
Classic and/or the MNGP/Remote.   I think that the -m message   is
missing for the Classic itself from that readme.txt file.

Just in case this eventually works,

The line....

sudo ./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl Classic_ALL_1849_150V_4-21-2014.ctl

-m uPlDrEMaLLfl   is the  message sent to tell the Classic to forward the code onto the Remote.
This will be repeated (-r)  for the MNGP/Remote to read and then erase its flash...

Then,
Classic_ALL_1849_150V_4-21-2014.ctl

is the code for the Classic, not the MNGP.   That line will want to be replaced with...

MNGP_ALL_1821_4-15-2014.rem

which is the code destined for the Remote.   If you were to update the MNGP with the
Classic code, it would have to be re-programmed with the MNGP code.

There is another message that tells the Classic to send the code for it which  is...

-m uPlDcLSaLLfl

and that option appears to be missing from the documentation so you should change the
first -m  message to this...

sudo ./mnupdate.py -z 2 -r -d /dev/ttyACM0 -m uPlDcLSaLLfl Classic_ALL_1849_150V_4-21-2014.ctl

If you haven't yet updated the Classic itself, try that.

There was also some different info from MidNite Mike for Linux or Mac OS X and I'll check on
that again tomorrow (Monday)

boB
OK. I think I got it right. Here's the result for the MNGP:

sudo ./mnupdate.py -z 5 -r -d /dev/ttyACM0 -m uPlDrEMaLLfl MNGP_ALL_1821_4-15-2014.rem
MidNite Firmware Updater
Copyright MidNite Solar Inc. 2012
Firmware size: 214352 bytes
Waiting for serial device.
<Press Ctrl-C to Cancel> . . . . .
Sleeping for serial port.
Opening serial port: /dev/ttyACM0
Sending upload command: uPlDrEMaLLfl
Repeating upload command: uPlDrEMaLLfl
Sleeping for flash erase.
<Uploading Firmware>
Update Failed: No ACK byte received

The result for the Classic was the same.

TomW

#43
Quote from: leeelson on May 19, 2014, 10:18:08 AM

<Uploading Firmware>
Update Failed: No ACK byte received

The result for the Classic was the same.

Same error I get. Tried a number of things but it always gives that error.

At least it is not just me doing something dumb.  ;D

It also has a Modbus connection issue that may or may not be related to the update failures.

Mine is going back on an RMA and hopefully the troubleshooters  at the factory will sort it out.



Tom
Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

boB

OK, Sorry it didn't work.  Let's see if Mike (from MidNite) can help at all.

Modbus is not used for code updating BTW.
K7IQ 🌛  He/She/Me