Cause BSD is the best? [emoji6]

Dude! You know, I had the good fortune over the years of dealing with them all. BSD? Check, both FreeBSD and OpenBSD. OS/2? Check. Ecs aka eComStation, the attempted reboot of OS/2? Check. Every version of DOS from 3.2 to 6 and then windows 3.0 to XP. Irix. Even ran into a database system called Pick. Linux, and OSX, which is just FBSD inside. And some fun times with slowlaris.

:-)

Sent from my GT-I9195 using Tapatalk

11 hours ago, plonkster said:

Dude! You know, I had the good fortune over the years of dealing with them all. BSD? Check, both FreeBSD and OpenBSD. OS/2? Check. Ecs aka eComStation, the attempted reboot of OS/2? Check. Every version of DOS from 3.2 to 6 and then windows 3.0 to XP. Irix. Even ran into a database system called Pick. Linux, and OSX, which is just FBSD inside. And some fun times with slowlaris.

:-)

Sent from my GT-I9195 using Tapatalk

Askies oom, nie geweet jy ken OS/2 nie!

HAHA, been there, got the T-shirt for all of them too. Luckily thing got easier after Windows 3.1 and Slackware.

53 minutes ago, SilverNodashi said:

Askies oom, nie geweet jy ken OS/2 nie!

I landed this sysadmin job straight out of university, and the boss was a somewhat fanatical OS/2 user.

On 7/11/2016 at 6:28 PM, viper_za said:

I think we are all waiting for Coulomb to decompile and compare them for us.

Sorry guys, I don't monitor this topic much (mainly the Inverters one), so I rely on notifications because someone mentions my name. And you did (thanks!) but I was slack and didn't check notifications.

But today I've had a quick look. So far, the main firmware changes are very few. In fact, the code follows the exact same addresses right up until the version number is printed out in a QVFW command. They do it in two chunks; the "0007" part and the "2.60" part. The latter is printed as a decimal number, with one digit before the decimal point and 2 digits after. So the immediate constant was 240 for 72.40, and it's 260 for 72.60. Guess what? 240 is less than 256, so the compiler can compile a one-word instruction to move this into the acumulator. But 250 is >= 256, so it has to use a two-word instruction with the constant 260 (0x0104) in the immediate field, in the second word. So the addresses all start to diverge at that point. This makes my high-tech comparison method invalid. What I do is look at one disassembly, use alt-tab to flip to the next task, which is always the other disassembly, and check for any differences. I flip them multiple times; after a while it becomes easy to spot any differences. (Did I mention that this was high tech? Don't try this at home ). I hope @plonkster and the others appreciate that little tech story.

So now it's a pain to check for differences after that point, because the addresses are different, the eye sees many irrelevant changes, so any relevant changes don't stand out. Sigh.

So I did the same with the function names window. It turns out that there is exactly one new function, named _sQFTYCommand(). The leading underscore is a C compiler thing; it's so that C function names can't clash with assembler function names (unless you named it that way, and they assume this is unlikely). All the Commands (routines that respond to commands from the PC port) start with the command mnemonic and end with Command. So this is the QFTY command [ Edit: actually QFTY5200, no CRC); this likely stands for Query Firmware ? ? . (Many commands start with Q for query or P for setting Parameters). I don't know what the T or Y stand for. What the function does is to print "VOLTRONIC POWER TECHNOLOGY CORP." and a carriage return. The usual leading open parenthesis ("(") and trailing CRC are omitted; they go to the trouble of turning off the _wCRCChkFlg flag to suppress the CRC (this happens in only one or two other commands; that means it's quite rare). My suspicion is that they are getting tired of having clones of their firmware turning up in knockoff competitors' machines. I'd say this is designed so that they can power up a competitor's machine in court, have it print their company's name, and have the prosecutor's lawyer yell "I rest my case!". Well, that's pure speculation on my part.

So: nothing exciting there, unless you are involved in Voltronic knockoffs. I sure hope that this isn't anything to do with firmware patches 

As for the SCC firmware, it's much harder going for me. Even the main() function has changed, so there could be significant changes there. It will take me weeks or months to figure out what they are, and I may not be able to describe the effects.

1 hour ago, Coulomb said:

As for the SCC firmware, it's much harder going for me. Even the main() function has changed, so there could be significant changes there. It will take me weeks or months to figure out what they are, and I may not be able to describe the effects.

Thanks Mike

Do you think it's worth it to just do the SCC firmware update then?
The main one seems kind of pointless then

5 hours ago, Coulomb said:

My suspicion is that they are getting tired of having clones of their firmware turning up in knockoff competitors' machines.

Oh I can see where this is going. Remember when dreamboxes got bricked because they were clones? I know a company who makes automotive diagnostic tools (Hex Diagnostics) and they have similar stuff in their code, or that is the rumour. If you use a cloned hardware device, the software detects it and actually DETUNES your vehicle (so you have to use the old version of the software). In other words, there is a real hardware-breaking physical war going on against the cloners, and the money saved initially is just not worth the frustration :-)

On 7/14/2016 at 3:00 PM, viper_za said:

Do you think it's worth it to just do the SCC firmware update then?
The main one seems kind of pointless then

At this very early stage, yes, it looks that way. But if you can hold off for a while, things might get a little clearer.

Just now, Coulomb said:

At this very early stage, yes, it looks that way. But if you can hold off for a while, things might get a little clearer.

100% I will await for your better findings. Thanks for the hard work with this Mike

Wonder who would have helped it it was not for @Coulomb and kie, respect sir, you seriously have my respect with your knowledge on all things Axpert.

The speculation that the firmware is used by pirated inverters, therefor needs to be protected, yo, that is rof.

 

But I just have to ... been sitting on my hands for days now to not say a word!!! Cannot hold it anymore.

You guys have noticed that not once did we cross to the Blue side here - who also has firmware updates yet the experience is like like, like ... actually there is no comparison you can make. 

Ok, it does mean that the color Blue does cost a wee bit more but it is worth it seeing this fiasco here. 

1 hour ago, The Terrible Triplett said:

The speculation that the firmware is used by pirated inverters, therefor needs to be protected, yo, that is rof.

You do know this is something that you wont ever know for the Blue company if someone does not reverse engineer the firmware?

What Mike is giving us here are finer details that is not shown in release notes. I'm pretty sure this is the kind of stuff @plonkster would also love to get his hands on this for the blue

40 minutes ago, viper_za said:

You do know this is something that you wont ever know for the Blue company if someone does not reverse engineer the firmware?

Mmmh, I wonder if such a thing would ever happen? You see the man who buys an Axpert often does so at least partly because of price. To put it bluntly, he buys that inverter because it's a cheap inverter. A man who is willing to buy a cheap inverter might buy a cheaper inverter "made in the same factory (TM)". So there is a market for this kind of thing. The man who buys a Victron is not in that market, so I would expect a lot less of that to happen. In other words, there is simply more money to be made selling fake Voltronics.

With that said, I know someone's already knocked off the MPPTs, or made one that looks the same. The Fanpusun.

Another possible reason: The Axpert uses "standard parts", at least part numbers that can be recognised as a Texas Instruments such and such. I'm not even sure what is used on the Victron. It looks a bit like a high PIC microcontroller, but who knows.

(Picture is of the old 19-series processor). Also note the part number of the MOSFETs on the sticker to the right :-)

Wow. You don't see much through-hole electronics like that any more. That could be a part of why it's so expensive - using more expensive PCB assembly methods. I'm not saying it's bad, just unusual to see these days.

6 hours ago, Coulomb said:

Wow. You don't see much through-hole electronics like that any more. That could be a part of why it's so expensive - using more expensive PCB assembly methods. I'm not saying it's bad, just unusual to see these days.

For small volumes, old-style might in fact be cheaper. I have no idea what kind of volumes they do on the smaller inverters. This is a 3-year old 1600va.

So far, the differences between SCC firmware revision 4.10 verses 4.00 seem to be to do with higher current hardware. At the start of main, three bits in port G are checked. If 000, full scale current seems to be 61.2 A as before; otherwise, it's 105.0 A. But it also checks for the pattern 010; if so, a new variable is set to 1 (and otherwise cleared); this seems to set some current limit to 80 A instead of 60 A. The fact that Rev 4.10 was supplied with an older model SCC indicates to me that these bits must be set to zero in older hardware. In other words, it must be safe to use the new firmware in older hardware, despite the fact that the newer hardware is capable of more current, and the older hardware is not.

I spotted a temperature limit going from 70°C to 85°C, so the higher current hardware must also run hotter at maximum load.

As to whether any minor bugs are fixed, it's impossible to tell at this stage. I did notice a comment of mine where I decided that they'd made a benign error in their source code, and it wasn't fixed in 04.10. So they're not superhuman   (It's also quite possible that I've made a mistake there; I didn't look in detail this time around.)

The function I'm most interested in (which I call AdjustChargeStage) hasn't changed at all. This is the one where they decide when to change from bulk to absorb and absorb to float.

So it looks like they are at least making provision for a 100 A SCC in the future. Otherwise, why change the shunt to just over 100 A from just over 60 A?

On 7/16/2016 at 0:06 PM, plonkster said:

 

On 7/16/2016 at 5:12 AM, Coulomb said:

Wow. You don't see much through-hole electronics like that any more. That could be a part of why it's so expensive - using more expensive PCB assembly methods. I'm not saying it's bad, just unusual to see these days.

For small volumes, old-style might in fact be cheaper. I have no idea what kind of volumes they do on the smaller inverters. This is a 3-year old 1600va.

 

Im thinking also serviceability, and parts availability. a bit like a toyota hilux hey? it is still their preferred method for their inverters, the smaller stuff like their charge controllers and the like is mostly surface mount.

On 7/17/2016 at 5:23 AM, Coulomb said:

So far, the differences between SCC firmware revision 4.10 verses 4.00 seem to be to do with higher current hardware. At the start of main, three bits in port G are checked. If 000, full scale current seems to be 61.2 A as before; otherwise, it's 105.0 A. But it also checks for the pattern 010; if so, a new variable is set to 1 (and otherwise cleared); this seems to set some current limit to 80 A instead of 60 A. The fact that Rev 4.10 was supplied with an older model SCC indicates to me that these bits must be set to zero in older hardware. In other words, it must be safe to use the new firmware in older hardware, despite the fact that the newer hardware is capable of more current, and the older hardware is not.

I spotted a temperature limit going from 70°C to 85°C, so the higher current hardware must also run hotter at maximum load.

As to whether any minor bugs are fixed, it's impossible to tell at this stage. I did notice a comment of mine where I decided that they'd made a benign error in their source code, and it wasn't fixed in 04.10. So they're not superhuman   (It's also quite possible that I've made a mistake there; I didn't look in detail this time around.)

The function I'm most interested in (which I call AdjustChargeStage) hasn't changed at all. This is the one where they decide when to change from bulk to absorb and absorb to float.

So it looks like they are at least making provision for a 100 A SCC in the future. Otherwise, why change the shunt to just over 100 A from just over 60 A?

I take it you open the firmware in a hex editor and look a the the code, without trying to decode it?

This raises the question, would it be possible to change the battery float and charge voltage a bit, safely?

6 hours ago, SilverNodashi said:

This raises the question, would it be possible to change the battery float and charge voltage a bit, safely?

If I remember correctly there was a hardware limitation Voltronic do have a high voltage unit.  

6 minutes ago, Chris Hobson said:

If I remember correctly there was a hardware limitation Voltronic do have a high voltage unit.  

Please elaborate?

The mosfets are only rated at 70v. Don't have the service manual infront of me to confirm this 100%. However remember 60v safety cut off in the spec sheet

2 hours ago, viper_za said:

The mosfets are only rated at 70v. Don't have the service manual infront of me to confirm this 100%. However remember 60v safety cut off in the spec sheet

ok well that's far higher than I need to work with

I would just like to adjust the float and bulk charge rates to accommodate my battery bank. 

16 hours ago, SilverNodashi said:

Please elaborate?

Silver have a look at Coulomb's reply below and then his post about the higher voltage Axpert

=============================================================================================================================

On 26/01/2016 at 11:49 AM, Mark said:

 

Given your experience with the firmware - is there a chance you can change the firmware to increase the upper limit of Menu item 26 (Bulk/CV) so we can Equalise our batteries at a higher voltage (currently 58.4).

It would not be hard with the firmware. The question is, will the hardware handle it? My feeling is that they had a figure of 59 or 60 V maximum in their minds, and that's why they chose 63 V rated capacitors and 75 V rated MOSFETs, for example. Remember that the MOSFETs have to deal with spikes over and above the instantaneous battery voltage, so their margins seem thin to me as it is.

 

Quote

I was thinking of 62V (or more) as Trojans for example need it to be 61.92 from my calculations and the data sheet.

Will the charging circuit allow this...  It would make a huge difference to alot of us.

 

 

I suspect that 62 V would be asking for trouble. 64 V would exceed the rating of the capacitors. It's a shame that Trojans require such non-standard voltages. I think to do a 64 V equalise, you'll need to use a separate charger. and disconnect the PIP while it's happening.

 

I don't even know about 60.0 V. It might work just fine, or most likely it will appear to work fine for a while,but will accelerate the ageing of the capacitors and cause the MOSFETs to eventually blow up (the capacitors protect the MOSFETs from the worst of the voltage spikes). How long this would take is hard to say without knowing more details about the design, and/or making tricky measurements.

 

So while I could technically do it, I'm reluctant to. Even if I cautioned people about the potential problems, if and when their inverters blew up, they may suddenly fell different about it.

 

There is also how the manufacturer, Voltronics, would feel about this. If I release a patch that ends up making their product look bad, they may not be so generous about ignoring my activities.

 

It may be that with higher voltage capacitors and MOSFETs, this could be done safely. But it's a lot of work, and not everyone has the skills to do this, or knows anyone nearby that can. So some people will likely just take the chance without modifying the hardware, and that could still lead to ill feeling.

 

So for now, that's a no. Sorry.

==============================================================================================================================

The  extended Axperts are now limited to 24V systems but some of the dual/tri MPPT models can charge up to 61V.

Look here.

Does anyone know if the 5kva duo or tri string units are available in za?

I hope Voltronics one day makes their controllers programmable that they can charge more types of batteries.

And that they start catering for i.e. Trojans equalization, for Trojans has been around far longer and has a good reason for the voltages they need.

On 7/29/2016 at 6:06 PM, SilverNodashi said:

I take it you open the firmware in a hex editor and look a the the code, without trying to decode it?

No way!   It's hard enough with a good disassembler and symbols. I use Ida Pro; the Professional Edition has TMS320 C2000 as a processor option, as well as Freescale HCS08 for the SCC firmware. I don't do anything particularly tricky; it's mostly a lot of hard work sorting out offset verses constant, separating the data from instructions, and so on. There is no ASCII in the hex image, so directly interpreting the hex code would be more than tedious, it would be impractical. There is some 160 KiB of flash memory in the DSP, and it's about 80% full.

Maybe one day Ida Pro's Hex Rays decompiler will work with all processors; last time I looked, it was limited to just 4 (x86, x64, ARM32, and ARM64). Then there would be less code to wade through.

Quote

This raises the question, would it be possible to change the battery float and charge voltage a bit, safely?

This is answered pretty well above. I think the present limit is 58.4 V for the CV voltage (parameter 26). That could conceivably be increased to say 60.0 V, but I think it would decrease the reliability unless you replaced the capacitors and MOSFETs with higher voltage parts (this has been done before, but it's a lot of work and presumably would shred any warranty, despite improving the inverter's reliability).

18 hours ago, Coulomb said:

No way!   It's hard enough with a good disassembler and symbols. I use Ida Pro; the Professional Edition has TMS320 C2000 as a processor option, as well as Freescale HCS08 for the SCC firmware. I don't do anything particularly tricky; it's mostly a lot of hard work sorting out offset verses constant, separating the data from instructions, and so on. There is no ASCII in the hex image, so directly interpreting the hex code would be more than tedious, it would be impractical. There is some 160 KiB of flash memory in the DSP, and it's about 80% full.

Maybe one day Ida Pro's Hex Rays decompiler will work with all processors; last time I looked, it was limited to just 4 (x86, x64, ARM32, and ARM64). Then there would be less code to wade through.

This is answered pretty well above. I think the present limit is 58.4 V for the CV voltage (parameter 26). That could conceivably be increased to say 60.0 V, but I think it would decrease the reliability unless you replaced the capacitors and MOSFETs with higher voltage parts (this has been done before, but it's a lot of work and presumably would shred any warranty, despite improving the inverter's reliability).

Replacing the CAPS and mosfet's isn't a big issue for me. And at some stage inverter will be out of warranty period so that doesn't bother me either.