Power Bank charging while stationary

[pd91223]

Is there any update as to which sound profiles now support charging of the Power Bank while the loco is stationary?

[ColinB]

Surely the charging of the "Power Bank" is not via software, usually it is a direct feed off the power feeds unless Hornby are doing something clever.

[P-Henny]

Colin you crack me up. You're a regular poster but it appears you don't read any post topics by others only your own topics of interest. Hornby's very unique HM7000 software based charging methodology has been discussed at length all over the forum, but it would appear only in numerous threads you have not read.

I have absolutely no interest in HM7000, but I still read the posts and threads relating to them just for my general interest and to keep abreast of developments, so was aware of what this thread raises as a question.

[ColinB]

The last post I read on the subject was the circuit diagram which definitely was using the raw powerfeeds. Interestingly before I put the post in I did wonder if they were using a port on the processor to supply the powerbank circuit, but then I though why would you, it is over complication for no notable gain. That is why I asked the question. Now if it was DCC I could understand it. There is also the issue that if the processor loses power the ports default to tri state and charging disappears, so the circuit resets before the Power Bank has chance to save it, unless you put an extra ton of circuitry in. No, I don't follow all the posts. Either way I asked a question which you answered, thank you.

[SteveM6]

All profiles were originally built with charging when moving while Tornado was tried with static charging. Feedback from the test team has resulted in all profiles being changed to static charging although the update has yet to be released to the public. It seems not a simple update of the app rather it’s a change to the profile software itself hence the extra testing that is being done.

[SteveM6]

The last post I read on the subject was the circuit diagram which definitely was using the raw powerfeeds.

 

 

The only circuit diagrams that have found their way on here are for fairly basic DIY stayalives - such circuit’s are readily available on the internet.

Hornby PB circuitry has not been published by them and anyone on the team has signed NDAs not to share anything they learn about the innermost parts of the system.

[ColinB]

SteveM6 anybody that has worked on electronics knows how they are doing it. They are using a port on the processor to charge a capacitor plus some other circuitry that feeds back to the regulator. I may not know the detail but it is fairly obvious by your statements on the subject. You clarified it when you said they can't fix it with the App, which you can't if they are using a port. They obviously have their reasons for doing it that way, I must admit in my experience any backup power supply which is what this is, you keep relatively simple. You definitely wouldn't control it from the processor unless you had a really good reason which by your last post indicates that they are beginning to realise. Either way I was just interested, there isn't any room in the loco I fitted the HM7000 to, to fit a "Power Bank" without cutting bits out which I never do.

[96RAF]

I explained way back a couple of things that affect this static/mobile charging, but for the benefit of clarity I will list them again.

First the decoder charging circuitry. There is a power feed from the decoder 12v rail and also a trigger from the decoder MCU that tells the Power Bank (PB) when to charge. The PB has a switching transistor that controls charging upon trigger.

Next - mobile charging was initially envisaged to preclude an expected current in-rush on those locos with the atomising steam unit (ASU - steam generator). Charging would only take place once the loco got moving.

Given the ASU equipped models are few and far away yet and folk are seeing stalling at throttle up it was decided to make charging happen with the loco static. This immediately cured the stalling problem.

To preclude any DCC programming track problems sometimes seen when a stay alive is installed, there is a 2 second delay built in, so this prevents a charging in-rush swamping the limited energy programming output as the short programming burst on DCC is over before the delay expires.

Finally as to why this will have to be an update by way of individual profiles and not just a simple decoder update. A decoder update could update the APROM (see the famous manual for an explanation of these xyzROM terms) but a profile update also updates the APROM as well as the SPIROM, hence you could update a decoder to enable static charging, but loading another profile over that would de-update that change, so all profiles have to be revised and users will have to reload the new version. It would have been good if the switch was a user choice by way of a CV change, but apparently it’s not as easy as that.

Although Steve is on the test team and has signed an NDA neither he nor others on the team are privy to the decoder or PB circuit detail schematics. I have a wider NDA with sight of these diagrams, so I can speak with authority on how these things work, even though I cannot post the diagrams or even a clip from them.

[SteveM6]

Well, I have never worked in electronics (I know, it’s obvious 😉) so I can neither confirm nor deny your comments regarding the choices Hornby have made.

As for finding space for the PBs, I’ve fitted fifteen - no cutting involved. In addition I’ve fitted twenty five TTS decoders with homemade stayalives on bother tender and tank locos or the HM7K powerbanks in really cramped locos. Only had to ‘ease’ one of them with a scalpel.

[ColinB]

Well I worked in it for the best part of 40 years, so I know a little bit about it and the software to drive it. Believe it or not when you design something the device comes with a big fat manual that normally gives you example circuits which is what most people use. As to the PowerBank, I recently bought a Zimo sound decoder for my P2, it is roughly the same size as the HM7000, with the standard speaker setup there was just no room for the large capacitor that came with it. Similarly with my Duchess and believe me I tried for over an hour. There again perhaps you are better at fitting them than me. I do have the issue that in many of my locos I use larger speakers so perhaps that is where all the space goes. I might eventually buy a Powerbank for the HM7000 I own just to see if it runs better but it is not top of my priority list. Sounds like I would need to update the software to get it to run correctly.

[Fishmanoz]

Colin, first the straight answer, in addition to RAF’s details: RTFM Appendix 7, Power Bank, page 120, Smart Charging.

First not so straight answer: I am amazed that anyone who has had more than casual engagement on the HM | DCC forum is not aware that first, the PB as originally implemented, only charges when the loco is moving but that problems this has caused mean that the soon-to-be-released sound profile updates include static charging. If that doesn’t mean that charging is under software control, not direct conventional circuit connection across the output of the bridge rectifier plus inrush control required for super caps, I don’t know what does.

Second not so straight answer: you clearly have more than casual engagement with this forum.

I’ll leave it there. I can’t think of anything further to say without at least being facetious, or worse derogatory, and neither are the way to go on these forums.

[SteveM6]

There again perhaps you are better at fitting them than me.

I might eventually buy a Powerbank for the HM7000 I own just to see if it runs better but it is not top of my priority list. Sounds like I would need to update the software to get it to run correctly.

 

 

Here’s a ‘homebrew’ added to a TTS in a 61xx.

 

 

The PB is plug and play on a TXS decoder - why would you think you would need to update the software? Unless you mean to get static charging - the app will likely prompt you to update - single button click. Even as a self confessed non electronics person, I can manage that.

[ColinB]

Fishmanoz what are you on about? SteveM6 explained it all, I have you saying one thing and P Henry saying something else. If the PB was across the bridge rectifier it would charge all the time, which it appears from all of your posts it doesn't. Then SteveM6 says in another post that there will be a new software release to fix the charging issue when the motor is not running, so to me that means that there is some software element. I assume that they are controlling it from a port on the processor, why I do not know, but they obviously have their reasons. The other suppliers put it across the reference voltage as it comes out of the regulator and ground, but if you did that then it would charge the capacitor up all the time until it reached regulator voltage which according to all your posts its doesn't. So basically you have explained it all to me in your posts so what are you on about? You guys do know what a port on a microprocessor is?

[ColinB]

SteveM6 your words "It seems not a simple update of the app rather it’s a change to the profile software itself hence the extra testing that is being done" to me that reads a software update to your HM7000 for each loco with PB. Of course they may have added it as a software command from the app which tells the existing software in the HM7000 to enable it if they were forward thinking enough. Seems pretty complicated seeing as all it does is power the circuit when there is no supply input to the HM7000, perhaps 96RAF can tell us why. Either way does it matter, I was just interested.

[LTSR_NSE]

Colin - why are you still expressing confusion when you have already understood all you wanted too?

If you read Paul, Steve, Fishy & RAF’s posts carefully, they have all given you complimentary (not contradictory) information & RAF has even given the reason you requested.

HM7k PB uses processor/software controlled charging (rather than basic bridge rectifier circuit controlled) to prevent PB from absorbing DCC CV write/read signals when loco is on a programming track. It is as basic/simple as that.

The app developer has included the ‘PB charging control instruction’ in the loco profiles (rather the core/general decoder software) - hence each profile needs updating/testing separately if a charging instruction change is implemented (e.g. from triggered-by-moving, to triggered-after-2-second-delay-of-decoder-powerup.)

[96RAF]

As all the information available has been posted and as all members have had their say and some have filed reports against the discussion and as this thread is obviously on a circular loop I have locked it for now. When further information becomes available I will open the discussion again.