Jump to content

Coulomb

Members
  • Content count

    364
  • Joined

  • Last visited

  • Days Won

    19

Coulomb last won the day on February 12

Coulomb had the most liked content!

6 Followers

About Coulomb

  • Rank
    Master
  • Birthday 05/11/1958

Profile Information

  • Gender
    Male
  • Location
    Brisbane, Australia
  • Interests
    Solar energy systems with storage; firmware for inverters and chargers

Recent Profile Visitors

1,856 profile views
  1. I hate that too. Our patched firmware reduces this 10 minute period to 2 minutes, which seems ample.
  2. It sounds strange; I agree with pilotfish that you could have other strange settings. See also http://forums.aeva.asn.au/viewtopic.php?p=55388#p55388 on the meaning of the three Output Source Priority setting values. It states that SOL tries not to use the battery unless all else fails, which is obviously not what you are seeing.
  3. This is the latest patched firmware 73.00b: http://forums.aeva.asn.au/viewtopic.php?p=66664#p66664 73.00c is being alpha tested. Its only change is more accurate reporting of battery current. It might be another week or two. You mentioned software to perform the updates; everything you need software wise is in the zip file. You also need a Windows computer and a USB to RS232 adapter; all this is discussed in posts linked from the above. If you are or may be paralleling machines, then you may want to choose a firmware version based on paralleling considerations, see this post : http://forums.aeva.asn.au/viewtopic.php?p=66644#p66644
  4. Axpert SCC MPPT v4.12 Firmware

    Ah. It goes with main firmware 72.90, which I've never heard of (though that means little), and it came from a no name brand machine that produced error 90 (which might be designed to catch clone manufacturers). My guess is that both 72.90 and 04.12 are unauthorised copies (perhaps with minor modifications) of older Voltronic Power firmware. I would not consider that to be a credible source. I'm not saying that there aren't other, credible sources, but that's not one of them.
  5. Battery lugs and terminals

    I would not. It's not designed for electrical joints. Something like this (seems expensive, you can likely do much better): https://www.wantitall.co.za/industrial/burndy-p8a-oxide-inhibiting-joint-compounds-penetrox-a-8-oz-container-size-squeeze-bottle-container-__b008klx2ry
  6. Battery lugs and terminals

    Not solder; solder seeps into the copper and makes an abrupt stiff to flexible interface that raises stress. Plus, soldering 35 mm^2 cable is nearly impossible. Use a compound to exclude the air and water from the crimp joint. The idea is that it squeezes out of the junction and only fills the gaps. It is mildly conductive, but of course nothing like the conductivity of copper. So don't use excessive amounts. Proper crimped lugs are essential for anything over about five amps.
  7. Axpert SCC MPPT v4.12 Firmware

    I'm wondering if 4.12 might be the one needed by the dual- and triple-SCC models. These Solar Charge Controllers have a different protocol, so that they can get their data over a daisy chained serial connection without interfering with each other. SCCs do have a "DIP switch" port (real or virtual, i.e. implemented by different PCB layout) that tells the firmware whether they are capable of 60 A or 80 A, so it's possible that they might do a similar trick to talk the two different protocols. If that's the case, then 4.12 might also be an enhanced version of 4.10 for single-SCC models. But maybe they don't or can't do the DIP switch thing for protocol selection, in which case 4.12 might be only for the dual- and triple-SCC models (i.e. it might not work in a single-SCC model at all). I can't seem to find anything on this now. Can you recall where you saw these screen shots?
  8. Axpert 5Kw PV input problem. Please help

    It's extra sad when the so-called experts get things wrong.
  9. Axpert 5Kw PV input problem. Please help

    All true. But the Axpert has to be ready for a BMS as well. I'm not aware of any command that would set the SOC, for example. Despite Voltronic Power claiming that they support Lithium Ion batteries. They still seem to be stuck in the lead age :-O
  10. Axpert 5Kw PV input problem. Please help

    In theory, it's nearly always possible to build some sort of bridge between two computers speaking different protocols and (as here) different hardware interfaces. But in practice, you'd leave that to the side trying hardest to enter the market. In this case, I'd say it is up to the battery manufacturer to support the Axpert charger, if and only if they see a big return on that considerable investment. It serves no purpose. And if you were less lucky, there is a chance that it could have caused damage.
  11. Axpert 5Kw PV input problem. Please help

    Nothing good will come of connecting the Axpert's RS232 port to the GCLS CAN ports, both of which misuse RJ-45 connectors. Fortunately they use different pins, so no harm should have come from this. Use the cable that came with the Axpert to connect it to the computer, via a USB to RS232 interface.
  12. Axpert 5Kw PV input problem. Please help

    It does sound like the premature float problem. Why don't Voltronic Power fix this? Their latest attempt to "fix it" seems to be to increase the "qualification time" from 30 seconds to 10 minutes. Perhaps they feel that more than 10 minutes of cloud is impossible. Do you notice that the charge current is low (perhaps due to cloud or shade) for the ten minutes before it stops PV charging? Older firmware (before 72.70) only need 30 seconds of shade, instead of 10 minutes. There is a simple test to convince yourself that you have this problem, described here (though you'll have to fire up your generator): http://forums.aeva.asn.au/viewtopic.php?title=pip4048ms-inverter&p=59896&t=4332#p59896 [ Edit: before 73.00 -> before 72.70 ]
  13. Axpert 73.00b funnies...

    Actually, we tend to use calls. Just out of laziness; it means a return statement can get you back, instead of another jump instruction that has to be changed for every new firmware revision. We're hoping that speed isn't an issue, with a ~100 MIPS processor, but this is one of the many things that we don't know for complete certainty. Certainly, all the UI changes are completely safe, but a few of the patches are to responses to CAN messages, which could conceivably have some real-time constraints. There are indications that the manufacturer isn't concerned about speed.
  14. Axpert 73.00b funnies...

    Heh, who knows. If the two main charge bugs eventually get fixed by factory firmware, that would reduce the impetus to keep going. I turn 60 this year, and Weber isn't far behind. I'd mumble something about the "young 'uns" taking over, but it seems that the younger generation aren't as interested in the low level stuff like stack offsets, the "triple XOR trick" (for swapping two locations without needing a temporary location), and so on. The two hopes for someone to take over (should that be a continued requirement) are (a) the Russians (and people of other countries) where security exploitation and defence is a much higher priority, and (b) virus researchers (wearing black, grey, or white hats) who buy a piece of equipment like an Axpert and see the need, if they come to a part of their lives when they have a bit more time.
  15. Axpert 73.00b funnies...

    Light years. I haven't looked at probably 80% of the firmware code, and I find it hard to understand ~30% of the 20% I have looked at (very rough figures). They have very clever code to handle the synchronised relay control, and handling paralleled machines (some with three phase). The contrast with some of the more pedestrian code is stark. It's certainly getting to be a lot of work. There is such a header for the TMS320F2809 based boards; it's a 14-pin JTAG header, and there are standard JTAG interfaces (some inexpensive, some four times the price of the inverter-charger and very sophisticated). I've used that header a few times. No fuse bits are blown, but as of a few years ago, they've started using security, which means we can't read their firmware directly any more . But if someone else writes an open source firmware, they would have little trouble flash programming it. Debugging is always a challenge when you have a high power inverter; just stopping the processor dead (at a breakpoint, say) while inverting or charging could be disasterous. And there is no desaturation protection to save the IGBTs or MOSFETs. For distribution to ordinary users, however, it would be more useful to use a similar upload scheme. Perhaps even the same protocol (with a high speed option perhaps), so that users can bootstrap to the new scheme. It would be a monumental exercise. I'm much less familiar with the HCS08 processor, as used by most of the solar charge controllers and the lower power inverters. I assume that there is a similar arrangement for them. We actually assemble some of the patches into a block of unused flash memory. So there we have the luxury of comments, meaningful variable names, and macros (if we needed them). But even ven those source code patches need a call instruction patched into the original firmware to call the patch, and sometimes a few NOPs need to be inserted (some instructions are two word, others a single word). These latter have to be done by hand. But perhaps a quarter of the patches are direct hex modifications. Usually these are only to NOP out a branch, or to change the value of an immediate operand. We actually publish the .txt file that we use to keep track of the patches, so you can see the gory detail if you really, really want. So we have to know the instruction set; being a DSP, it's not actually intended for use by humans (only by the back end of a compiler). There are remarkable gotchas and inconsistencies in the C2000 instruction set. Weber also wrote a spreadsheet to calculate the checksums for us. The tool that gets most use is Windows Notepad (I kid you not). We use TI's Code Composer Studio to assemble those patches or partial patches that have assembler source code. I suppose one day we might write part of the patches in C. And of course, every time there is a new firmware version that we get a hold of, we have to find the addresses of all the patch locations; every one of them will have moved.
×