Here is a link to the newest BETA firmware it has a bunch of network fixes as well as a lot of optimization for the traffic calling out to My Midnite
http://fusion.midnitesolar.com/MidNiteSolarUpdate_1849_4-21-2014_v4.43.exe (http://fusion.midnitesolar.com/MidNiteSolarUpdate_1849_4-21-2014_v4.43.exe)
Sorry -- gotta add a correction: this version doesn't have the optimizations for mymidnite. Those are still in the works....
My Bad,
-A
Is the OS X updater available for this version as well?
Quote from: atop8918 on April 22, 2014, 08:45:00 AM
Sorry -- gotta add a correction: this version doesn't have the optimizations for mymidnite. Those are still in the works....
My Bad,
-A
Oh ? OK, but this has a bunch of bug fixes. Also, it will accurately report the necessary information to debug why a Classic is Watchdog resetting but the Local App does not show this information at this time so another modbus application will have to be involved.
I will get the OS X and Linux/Unix/Python updater going and should be up here by tomorrow or later tonight.
Here you go. David...
http://fusion.midnitesolar.com/MidNiteSolar-Classic_PYTHON-Updater_1849_4-21-2014_v4.43.rar
Thanks boB, I will try it out! :)
Quote from: Halfcrazy on April 22, 2014, 07:58:27 AM
Here is a link to the newest BETA firmware it has a bunch of network fixes as well as a lot of optimization for the traffic calling out to My Midnite
So what are these network fixes targeting? Are they trying to fix the local app disconnects? Or are they targeting MyMidnite issues. Sounds like the MyMidnite fixes aren't there yet.
The fixes are as follows:
- It was possible for the advertise state machine to close a connection without cleaning up therefore "leaking" connections. Eventually other tasks were unable to connect.
- In DHCP mode the main state machine was performing ARP requests before address was assigned
- DNS state machine was not honoring the ttl field so entries were not being refreshed.
- There was a unhandled state in the DHCP state machine which occasionally resulted in mymidnite lockup
- MAC peripheral was in pass-through mode resulting in software-only filtering of packets. Too much traffic for the software to handle on busy networks resulting in poor connectivity.
- Increased buffer size to prevent packet segmentation
- disabled segmented packet processing in the stack due to stack bug.
- disconnection logic had potential issues -- cleaned up in local and remote tcp state machines
- basic architectural changes to support PC port for enhanced testing purposes
Verified 125 hours continuous testing:
classicStats.jar ip.ip.ip.ip count=100000 [no delay]
classicStats.jar ip.ip.ip.ip count=100000 [delay timeout]
ping ip.ip.ip.ip -l 1000 -n -1
Web: Enabled
DHCP: Enabled
DNS enabled (MM:0.0.0.0)
Thanks Andrew, will give it a try and report back next week.
Incidentally, the optimizations for MyMidNite are just that -- optimizations, not necessarily bug fixes although once complete they should improve general performance of the mymidnite interface dramatically.
Okay, loaded 1849 Classic firmware with 1821 MNGP and 1839 Network this afternoon.
I've now seen two incidents of the Alert with the Local App that the PC and Classic are more than 10 minutes different on their clock settings. I checked the Classic time when I got the first alert and Classic and the PC both have the same correct time. So don't know why I'm starting to see these alert after changing to this firmware.
I've only see one disconnect with the LA over a period of 4 hours of it running on my Laptop. I'll be here all next week so will see if we see any more. I think they occurred for me while interacting with the data functions which I haven't done a lot of today.
Quote from: Resthome on April 26, 2014, 10:26:22 PM
Okay, loaded 1849 Classic firmware with 1821 MNGP and 1839 Network this afternoon.
I've now seen two incidents of the Alert with the Local App that the PC and Classic are more than 10 minutes different on their clock settings. I checked the Classic time when I got the first alert and Classic and the PC both have the same correct time. So don't know why I'm starting to see these alert after changing to this firmware.
I've only see one disconnect with the LA over a period of 4 hours of it running on my Laptop. I'll be here all next week so will see if we see any more. I think they occurred for me while interacting with the data functions which I haven't done a lot of today.
OK, thanks John. Keep us posted. So far as I know, as long as there isn't some hardware hiccup, it's working pretty well overall.
Quote from: Resthome on April 26, 2014, 10:26:22 PM
Okay, loaded 1849 Classic firmware with 1821 MNGP and 1839 Network this afternoon.
I've now seen two incidents of the Alert with the Local App that the PC and Classic are more than 10 minutes different on their clock settings. I checked the Classic time when I got the first alert and Classic and the PC both have the same correct time. So don't know why I'm starting to see these alert after changing to this firmware.
I've only see one disconnect with the LA over a period of 4 hours of it running on my Laptop. I'll be here all next week so will see if we see any more. I think they occurred for me while interacting with the data functions which I haven't done a lot of today.
I can confirm the time bug. Mine keep doing that here. The screen goes yellow and it says the time is off and then in a few seconds corrects itself. I "assume" this is in the Local App not the Classic but IDK?
I also had a lot of disconnects while using "Offline" data. It took 4-5 tries to get it to download so I could export.
Ryan
A few comments on the Mac OS X installer. I am using Mac OS X 10.9.2.
1) The "moon3.gif" was missing. You get an error without it so I used another image file for it and renamed it "moon3.gif".
2) I never saw the "Waiting for serial device."
3) RAR compression is not a compression format that is easily handled on OS X without downloading some third party app. Zip would be more appropriate. If you zipped those files on a Mac it would even preserve the execute permissions on the "mnupdate.py" file so you would be able to get rid of that entire paragraph on "chmod"ing it.
Because I never saw the "Waiting for serial device" I was not able to update the firmware. I ended up hauling my 27" iMac (which was not fun :) ) that has VMWare and Windows Vista on it down to the Classic so I could update it.
Another thing I notice this morning while in Bulk MPPT the fans started running when the FET Temp was at 45.6 C. I thought this got adjusted up (Firmware 1758-1759) and it seemed like with 1795 they didn't come on until around 52-55 C. Did this get changed?
Quote from: Halfcrazy on April 27, 2014, 03:33:07 AM
I also had a lot of disconnects while using "Offline" data. It took 4-5 tries to get it to download so I could export.
Ryan
Ryan the one disconnect I saw yesterday was with the "Offline" data. BTW the Classic WDT reset that I reported here still happens with this version.
http://midniteforum.com/index.php?topic=1754.0 (http://midniteforum.com/index.php?topic=1754.0)
Quote from: Resthome on April 27, 2014, 12:23:55 PM
Quote from: Halfcrazy on April 27, 2014, 03:33:07 AM
I also had a lot of disconnects while using "Offline" data. It took 4-5 tries to get it to download so I could export.
Ryan
Ryan the one disconnect I saw yesterday was with the "Offline" data. BTW the Classic WDT reset that I reported here still happens with this version.
http://midniteforum.com/index.php?topic=1754.0 (http://midniteforum.com/index.php?topic=1754.0)
Yes, the offline data reading but is still there and will be for a while. The way around this is to not have the MNGP sitting in the LOGs screen when downloading via the local app.
Was that the case, John ? It should not reset from just downloading the offline data from local app if the MNGP is not doing the same thing.
And, David...
"3) RAR compression is not a compression format that is easily handled on OS X without downloading some third party app. Zip would be more appropriate. If you zipped those files on a Mac it would even preserve the execute permissions on the "mnupdate.py" file so you would be able to get rid of that entire paragraph on "chmod"ing it."
I thought that the usual Unix and Linux OS's could un-archive RAR files. I will change this to
a TAR or GZIP format (or maybe both ?).
I'm not sure why it needs the moon.gif logo ? Will look.
Thanks
Quote from: boB on April 27, 2014, 05:48:13 PM
And, David...
"3) RAR compression is not a compression format that is easily handled on OS X without downloading some third party app. Zip would be more appropriate. If you zipped those files on a Mac it would even preserve the execute permissions on the "mnupdate.py" file so you would be able to get rid of that entire paragraph on "chmod"ing it."
I thought that the usual Unix and Linux OS's could un-archive RAR files. I will change this to
a TAR or GZIP format (or maybe both ?).
I'm not sure why it needs the moon.gif logo ? Will look.
Thanks
I've NEVER seen anything distributed for the Mac using RAR :P TAR GZIP would work (.tgz) and is supported directly from the Finder in OS X.
Moon3.gif is referenced in the python file.
Quote from: boB on April 27, 2014, 05:48:13 PM
Yes, the offline data reading but is still there and will be for a while. The way around this is to not have the MNGP sitting in the LOGs screen when downloading via the local app.
Was that the case, John ? It should not reset from just downloading the offline data from local app if the MNGP is not doing the same thing.
boB , that was the case, it is avoidable if your aware of the issue. Still seeing the LA network Disconnects but only when in the Data Tab and mostly if you have been in the Offline Data window. Otherwise the network seems to be more stable with the LA than in the past. Will be looking over the data tonight, but so far everything seems to be good. No problems with MyMidNite so far. Would like to see the WBjr information added to MyMidNite.
+1 on the WBJr info on MyMidNite, John.
I've been working on this as well -- the mymidnite optimizations referenced before are part of the work associated with the WBJr. info. Slow but steady progress.
Thanks,
-A
As far as network changes, my OS X app had been polling every 0.5s for data and so far no issues. With older firmware the Classic would eventually cease to respond to Modbus commands.
Quote from: atop8918 on April 28, 2014, 02:52:06 AM
+1 on the WBJr info on MyMidNite, John.
I've been working on this as well -- the mymidnite optimizations referenced before are part of the work associated with the WBJr. info. Slow but steady progress.
Thanks,
-A
Thanks Andrew.. that will be a great improvement for MyMidnite.
Great news, David. Please let me know if it loses connectivity.
Thanks,
-A
Today I updated to 1821 MNGP 4-14-2014 and 1849 4-21-2014 Classic firmware .
After charging all day the SOC is only showing 7% even though I know the batteries are full because it went through absorb and float . The only place I read the SOC on the MNGP is on the Whizband Junior Shunt status screen. It is flashing 7% . Didn't the SOC also used to show up on one of the other MNGP status screens ?
Last week I helped a friend update their system same updates and they said their SOC is not going to 100% either. I was going to wait until I posted this until tomorrow to see if it resets to 100% tomorrow morning but since my friend said theirs hasn't I thought I would ask if anyone else is seeing this same thing after the update ?
I have set the battery amphour size via Local Status App and other settings that were in the SOC setup. The only thing I didn't set was Whizbang net amp hours resets at full - that is still at default setting No.
Both systems had the VMM reset by shutting power off and holding right and left arrow in on power up after the update .
Quote from: ClassicCrazy on May 03, 2014, 10:06:28 PM
Today I updated to 1821 MNGP 4-14-2014 and 1849 4-21-2014 Classic firmware .
After charging all day the SOC is only showing 7% even though I know the batteries are full because it went through absorb and float . The only place I read the SOC on the MNGP is on the Whizband Junior Shunt status screen. It is flashing 7% . Didn't the SOC also used to show up on one of the other MNGP status screens ?
Last week I helped a friend update their system same updates and they said their SOC is not going to 100% either. I was going to wait until I posted this until tomorrow to see if it resets to 100% tomorrow morning but since my friend said theirs hasn't I thought I would ask if anyone else is seeing this same thing after the update ?
I have set the battery amphour size via Local Status App and other settings that were in the SOC setup. The only thing I didn't set was Whizbang net amp hours resets at full - that is still at default setting No.
Both systems had the VMM reset by shutting power off and holding right and left arrow in on power up after the update .
Something is strange because the SOC should not be flashing after it goes to Float the first time after powering up. Did you check the Aux 2 setting for the WBjr? Also the very first Status screen some times called Home screen should alternate the Classic current stage and %SOC number. Another thing to check on the WBjr status screen is the Temp reading, make sure it is not reading -50C.
The latest MNGP code (along with the Classic code) will not show -50 degrees anymore when the Aux2 is not talking with the WB Jr. Instead it says "NO WB" to let you know.
So, I'm not sure what is happening here because when naturally going from Absorb to Float the SOC% should go to 100% and stop flashing. When it stops flashing/Blinking in the WB Jr. status screen, the SOC% should then be
alternatively be showing on the main status screen message area along with the charging stage, etc.
Another thing you can try is to go to go to the WB Jr. screen and then to the MORE screen. Then, hold down the LEFT ARROW key while then pressing the ENTER key for a second or two. This ~should~ set the SOC to 100% and also stop the flashing.
I don't know why the SOC% did not reset to 100% when it went to Float. This software has been tested pretty good.
Dang ! Try the force 100% thing in the MORE screen and please let us know what happens.
Thanks
Yes holding the left arrow and enter key set it to 100% and now on the 1st MNGP status screen bottom right is alternating between Batt 100% and Bulk MPPT . But I do notice that when I use status button to scroll through the sceens on MNGP when I get back to first Main Status screen sometimes MNGP will beep , sometimes the bottom right will flash a few strange things like Batt 476%, SMA Mode off ( think that is what it said ) , Float, but only once and then go back to correct alternating Batt 100% / Bulk MPPT . Now after trying that for awhile it seems to be more stable and just display what it is supposed to when going between screens .
I guess I never read manual before because I just discovered that if I hold Status Screen in it gives me info on that screen. Took me awhile here to understand what Enter forces new Sheep meant !
Later today after the batteries fill up I will shut off the PV and put some loads on it to see if it counts down from 100 % .
Thanks for the help.
I just checked my Classic here to make sure that the SOC% stops flashing when it goes from Absorb to Float (naturally goes to Float) and it did set it to 100% and stopped the flashing. I tried this for both Ending Amps and timed Absorb to Float transition. This was build 1849.
So, I'm not sure what happened in your case where it did not set itself to 100%. That's a good one.
Been working that way for me also boB.
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.
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. .
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.
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.
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.
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.
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.
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?
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
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
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
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.
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
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.
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
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.
Did this ever get resolved? I also get the "No ACK byte received" message when using -z 3
Without the -z 3, I've been getting a "ord() expected a character, but string of length 0 found" message
I managed to update the Classic's firmware, but have been getting these errors with the Graphic panel updates.
Went back to the camp and tried the MNGP update again - with 4 different USB cables. All attempts resulted with the "No ACK byte received" message, regardless of whether I included -z 3.
I wasn't smart enough to bring the notes from Tom to test the system.
It sure would be nice to get this updated so that I can use the WBJr
Quote from: Rybren on July 13, 2014, 10:09:15 AM
Went back to the camp and tried the MNGP update again - with 4 different USB cables. All attempts resulted with the "No ACK byte received" message, regardless of whether I included -z 3.
I wasn't smart enough to bring the notes from Tom to test the system.
It sure would be nice to get this updated so that I can use the WBJr
Will check with the Python expert(s) tomorrow (Monday) on this
Thanks boB