AXSPort firmware 3.15 Clues

Post Reply
Forum Whiz
Posts: 37
Joined: Mon Oct 26, 2009 10:51 pm
My RE system: (being majorly revised...)

AXSPort firmware 3.15 Clues

Post by LorenAmelang » Tue Apr 05, 2016 3:04 pm


The firmware package actually includes a changelist:

- Fixed FTP client directory detection issue.
--> Well, yes, the directory now shows up properly, even in IE or Firefox (not in chrome or safari...), but I still can't FTP an actual file. Cyberduck just tries to connect forever, FileZilla (I still have a Linux version that didn't come with malware) locked up and forced a restart of Ubuntu 14.04, and Firefox says Can not change directory to '/DATALOGS/16040314.CSV'. As before, only the ancient WS_FTP95 can actually transfer files. (Hey OutBack, it is the 21st century now! Please test with programs that aren't 21 years old!)

- Updated data log file location by separating each months file into a separate sub-directory by month and year (i.e. 01-2016).
--> Not really. The directories get created, but nobody sees the new files as being inside the new directories. All of them show up at the top level of DATALOGS. In the permissions section of the raw debug logs, the directories are marked as directories, the files are not - but none of them include any read or write permissions! Still, that doesn't explain why Firefox would think the new files are directories.

- Improved reliability reporting of events to OPTICS.
--> I'm no longer seeing a non-existent device constantly sending updates and receiving errors.

Known Issues:
-SunSpec maps are updated and will required existing custom software to be updated to processes updated SunSpec blocks.
--> Well, it is hard to tell, since there doesn't seem to be a new SunSpec map spreadsheet. Inside the download:
AXS Port Development Package
AXS Port Development Package 105
AXS Port SunSpec Map.xls <-- Not 3.15, not 3.11, but not the 1.05 I have, either!
outback.c (11/6/2015 9:38 AM, AB99FA04, 154 KB)

Code: Select all

         /*	outback.c	version 0.98	Jam. 7, 2014
		   *	Written by Daniel Lloyd. 2011-2014.
		   *	Property of OutBack Power Inc.
That disgustingly documented file actually builds the proper Shell for 3.15!
How are we supposed to know that?

For anyone who uses Shell, here's the 3.15 version:
OutBack Commnunications Shell <-- still mis-spelled!
Version 3.0.105
--> Aha! The "105" number is the internal version of the Shell program that goes with firmware 3.15.
The Shell for 3.11 was "100".
The Shell for 1.05 was "97".
So it is just a nasty coincidence that the latest dev package happens to have the same number as the obsolete firmware version before last. That still doesn't excuse the failure to update the internal source file identity. (Or maybe this update we waited until March 2016 to receive was really completed way back in November 2015?)

Turns out in my situation with only the FM80, none of the SunSpec items I use were moved, I did not need to revise my app. Somewhere up above the 400's things were added...

So now that I have 3.15 installed, I can "Verify" my MAC address in Optics. Once you can get in, you can see the info that might have explained why you couldn't get in before:

Known Issues
There is a known issue with firmware version 3.11 which prevents a system without an OutBack HUB, or a system with only one device attached to a HUB, from being able to successfully connect to Optics. If running such a configuration we recommend using an earlier firmware version.
--> So I have a single FM80 on an AXSPort with no Hub - apparently this bug affects the AXSPort as well as the Mate. In all the eMails and phone calls with OutBack support over the last year, nobody ever even asked if my configuration matched this bug!

Known Issues
Under certain conditions the Mate will fail to reconnect to the OpticsRE server until it is power-cycled. We are actively working on replicating and resolving this issue.
--> Not clear if this means after the update or after any network interruption. I found my AXSPort did not connect to Optics, or even to the time server, after the update until it was power cycled once more. Since then it re-connects to Optics automatically after I block its access and then allow it again. At least it begins POSTing data immediately. In the Optics web interface, I see "Uploading backlog data", but no new graph points since the interruptions. The first test interruption created "online>offline" and "offline>online" events, but the second created an "offline" event and stuck there. Looks to me like the problem is in the cloud service.

Today, with no more events of any kind showing in Event History, it shows no Dashboard data until 1 PM, when it suddenly draws a single bar. I don't understand...

Bug Fixes
Fixed an issue that was causing event history items to display out of order. They are once again sorted by time with the most recent events listed first.
--> Only if they all fit in the chosen "items per page" count! If not, you see somewhere in the middle of the list, and can't scroll to the newest ones. There is no next/previous page selection! The only way to see the newest items is to select Show All!

On Optics "Event History", clicking Refresh resets your "Items per page" to 50, and if you were showing all, it then goes back to showing the earlier events instead of the latest ones.

The Event History is so long at the moment because it looks like every power cycle of the ASXPort does a big reconfigure sequence of all the things you can control from Optics. About 80 event items for each power cycle! Each item goes through a sequence like this (newest items at top):
Config CC 0 Absorb Time 0 1 Hours On-Site 4/3/2016 15:26 31
Config CC 0 Absorb Time 0 1 Hours On-Site 4/3/2016 15:26 57
Config CC 0 Absorb Time 1 0 Hours On-Site 4/3/2016 15:26 84

Most of the items are understandable, but two of them have exactly the same label:
Config CC 0 Enable Voltage > 0 140 VDC On-Site 4/3/2016 14:39 94
Config CC 0 Enable Voltage > 0 28.8 VDC On-Site 4/3/2016 14:39 95
Config CC 0 Enable Voltage > 0 140 VDC On-Site 4/3/2016 14:39 120
Config CC 0 Enable Voltage > 0 28.8 VDC On-Site 4/3/2016 14:39 121
Config CC 0 Enable Voltage > 140 0 VDC On-Site 4/3/2016 14:39 147
Config CC 0 Enable Voltage > 28.8 0 VDC On-Site 4/3/2016 14:39 148

Pretty clearly one of them is:
40646 270 : CCconfig_AUX_PV_Limit_Volts 140.0 V

But the other could be:
40616 240 : CCconfig_Absorb_Volts 28.8 V
40622 246 : CCconfig_EQ_Volts 28.8 V
40643 267 : CCconfig_AUX_Low_Batt_Reconnect 28.8 V
40645 269 : CCconfig_AUX_Vent_Fan_Volts 28.8 V

In the Optics config sections:
Misc. > Enable Voltage > Default: 28.8 VDC
Battery Charging > Absorb Voltage > Default: 28.8 VDC
Battery Charging > EQ Voltage > Default: 28.8 VDC

The name "Enable Voltage" doesn't help me much...

So now that I can get into Optics, I have set the "Ping Time" from 30 seconds to 120 seconds, the maximum allowed. But it seems to have no effect on the actual traffic. To create those graphs that show power production and battery voltage _once per hour_, Optics is POSTing updates every ten _seconds_! For my single OutBack device, there is a 20 second pattern, with one empty POST and the next one content-length 998. It adds up to just about one MB per hour, adding up the packet lengths in Wireshark, but closer to 4 MB per hour as charted by my router (totally don't understand that). That adds about $6 per month to my internet bill... Presumably for each OutBack device connected...

OutBack must realize many of their customers live on the fringes of the net where bandwidth is expensive. Why ever would they upload ten-second data and give us no choice in the matter? And once they have this extravagant data, why do they reduce it to hourly points on the graphs? Disgusting!

After the firmware update and some successful Shell exploration, I noticed my AXSPort showed an error - in fact:
>> e
ERROR: Last Write Invalid Value
ERROR: SMTP Send Failed
ERROR: Write attempt while locked.
Unlock with write password (command 'u')
ERROR: Device Firmware Update Invalid
ERROR: Device Firmware Update File Not Found
ERROR: Device Firmware Invalid Update File
ERROR: Device Unsupported Operation
ERROR: Error reported on device 11

After that it was displaying garbage:
*** OutBack OutBack Block ***
40069 9 : OutBack_SunSpec_DID 48836
40070 10 : OutBack_SunSpec_Length 48836
40071 11 : OutBack_Major_Firmware_Number 48836
40072 12 : OutBack_Mid_Firmware_Number 48836
40073 13 : OutBack_Minor_Firmware_Number 48836
40074 14 : OutBack_Encryption_Key 48836
40075 15 : OutBack_MAC_Address FM80-150VDC
40082 16 : OutBack_Write_Password FM80-150VDC
40090 17 : OutBack_Enable_DHCP !16938
40091 18 : OutBack_TCPIP_Address
40093 19 : OutBack_TCPIP_Gateway
40095 20 : OutBack_TCPIP_Netmask
40097 21 : OutBack_TCPIP_DNS_1
40099 22 : OutBack_TCPIP_DNS_2
40101 23 : OutBack_Modbus_Port 46837
40102 24 : OutBack_SMTP_Server_Name ??
40122 25 : OutBack_SMTP_Account_Name ??
40138 26 : OutBack_SMTP_SSL_Enable 16938
40139 27 : OutBack_SMTP_Email_Password ?~???X?g
40147 28 : OutBack_SMTP_Email_User_Name ?~???X?g
40167 29 : OutBack_Status_Email_Interval 0
40168 30 : OutBack_Status_Email_Status_Time 48836
40169 31 : OutBack_Status_Email_Subject_Line ?~???X?g
40194 32 : OutBack_Status_Email_To_Address_1 ?~???X?g
40214 33 : OutBack_Status_Email_To_Address_2 ?~???X?g
40234 34 : OutBack_Alarm_Email_Enable 0
40235 35 : OutBack_Alarm_Email_Subject_Line ?~???X?g
40260 36 : OutBack_Alarm_Email_To_Address_1 ?~???X?g
40280 37 : OutBack_Alarm_Email_To_Address_2 ?~???X?g
40300 38 : OutBack_FTP_Password ?~???X?g
40308 39 : OutBack_Telnet_Password ?~???X?g

Several times when I tried to dump All items the unit segfaulted:
40473 157 : OutBack_Gateway_Type !56609
40474 158 : OutBack_System_Voltage 56609 V
40475 159 : OutBack_Measured_System_Voltage 48843
40476 160 : OutBack_AGS_AC_Reconnect_Delay 48843 mins
40477 161 : OutBack_Multi_Phase_Coordination 56609
Segmentation fault (core dumped)
Twice at that same location...

The power cycle seems to have fixed that. The fancy new "how to update" video doesn't say anything about a power cycle being required...

The good news is that
40660 284 : CCconfig_Set_Log_Day_Offset 0 days
is now writeable again, so my system status app can get the info it needs. Thanks for small favors...

Post Reply