EEZ Bench Box 3 - Sequel to EEZ H24005

[prasimix]

If you are asking about File save option it's below every image...

That doesn't save the chart as zoomed in, just the overview. I'm looking at currents of about 1-100mA so I get just a flat line on the saveable view.

Then why not use data logging, which will create a file that you can view in EEZ Studio, or export to .csv for displaying elsewhere?

[prasimix]

Such event should be recorded in log file

Yep, it is:

Code: [Select]

2020-11-12 14:40:29 INFO Default profile changed to 0
2020-11-12 14:41:01 INFO Power up (v1.5)
2020-11-12 14:41:01 DEBUG POR/PDR reset flag
2020-11-12 14:41:01 DEBUG PIN reset flag
2020-11-12 14:41:01 DEBUG BOR reset flag
2020-11-12 14:41:04 INFO NTP refresh succeeded
2020-11-12 14:41:48 INFO Power up (v1.5)
2020-11-12 14:41:48 DEBUG POR/PDR reset flag
2020-11-12 14:41:48 DEBUG PIN reset flag
2020-11-12 14:41:48 DEBUG BOR reset flag
2020-11-12 14:41:49 INFO NTP refresh succeeded
2020-11-12 14:53:10 INFO Ch1 output on
2020-11-12 14:53:10 INFO Ch2 output off
2020-11-12 14:53:10 INFO Recall from profile 1
2020-11-12 14:53:38 INFO Power up (v1.5)
2020-11-12 14:53:38 DEBUG Independent watchdog reset flag
2020-11-12 14:53:38 DEBUG PIN reset flag
2020-11-12 14:53:38 ERROR Watchdog reset
2020-11-12 14:53:40 INFO NTP refresh succeeded
2020-11-12 14:55:29 INFO Ch1 output on
2020-11-12 14:55:29 INFO Ch2 output off
2020-11-12 14:55:29 INFO Recall from profile 1
2020-11-12 14:55:51 INFO Power up (v1.5)
2020-11-12 14:55:51 DEBUG Independent watchdog reset flag
2020-11-12 14:55:51 DEBUG PIN reset flag
2020-11-12 14:55:51 ERROR Watchdog reset
2020-11-12 14:55:53 INFO NTP refresh succeeded
Rather a lot of NTP refreshes. It is set to 720 minutes so shouldn't be happening every 2 mins or so. Speaking of which, I couldn't get it to sync to either the default server or 0.uk.poo.ntp.org (my usual source). Works fine to my server on the LAN, so I wondered if it were Internet access, but the gateway seems correct, DNS OK. Since it's working to my server I put off thinking about it any more

NTP refresh occurs on each power up and then with set frequency (default is 720 minutes). Don't understand why it couldn't get into sync if NTP refresh succeeded is recorded into event log.

[prasimix]

If you have a profile set and decide to make that the boot profile, you drop in there and change the 'no' to a 'yes'. The settings are whatever that profile is set for. Press save and the settings are now whatever the current settings are, which are shown if you open the profile again.

I think that when you hit save, whatever is being shown as the settings values are what get saved. If that's out of step with the current setup, too bad - you save what you see.

Light dawns! It seemed obvious to me that to change the boot profile you go in change the 'this is the default' to yes, hit save to save it. But, in fact, you don't need to press save - it is sticky just by changing it.

That's what led to my issue - save just copies the current settings into the profile, wherease I assumed it saved whatever was on that page to... well, wherever the config is saved. Coming from a desktop GUI that's how they all work, so the expectation was that this does the same too. But the real function of save is essentially in the opposite direction.

Given that, I'm not sure 'save' is the right word to use there, although I can't offhand think of a better one.

How did you come to the conclusion that you should press the Save option? As you said Use as a Power-up profile needs to be set to Yes if you want the parameters of that profile to be used at startup. Save is there all the time and allows you to save the current parameters to the profile: if you did not change them after the start, this action will have no effect, otherwise the new parameters will be saved.

[prasimix]

Dear all, situation is the following: we currently have 3728 subscribers to the Crowd Supply campaign and that number is growing every day. However, everyone seems to be watching and waiting for something or are terrified of the problems we had with completing the kits. If they are waiting for the next positive update, then I would give it to them and I would need your help. I would start publishing a series of updates that will include user testimonials and field reports, to see if that would move us from the deadlock.
Yes, some of you already told us what they think about BB3, but this time I'd like to collect your testimonials in more structured way. It doesn’t have to be an essay. A statement of one or two sentences will suffice. Your EEVblog forum instead of real name will be used if you want. You can post your feedback here or send it directly to me by email on eez@envox.hr

Many thanks in advance.

[PlainName]

Unfortunately this will require deeper digging as it is not supported in HAL.

Oh well. Nevertheless, the mouse implementation is great. It's the small touches one wouldn't otherwise think about, such as needing a button press and mouse move to exit standby.

[PlainName]

Is it OK to set, say, one channel to 4V and the other to 5V and then connect them together?

I am exercising a battery charger, so have one channel pretending to be USB at 5V and the other pretending to be the battery at 4V. It is currently working (albeit with the 4V channel not sinking current), but when I first set up I got a consisten situation where a channel could be unconnected (that is, no physical connection to anything) yet show the correct V out on the display with the green LED lit but no actual output (i.e. a voltmeter shows 0V). No overcurrent or anything untoward, just no output.

Naturally, I can't replicate it now and the log showed nothing unexpected. So I wondered if I might've tripped something that disabled the outputs (it happened on both channels, separately, and I think a mains power cycle fixed it but I can't be sure - wasn't taking notes and now I am it's not happening...)

[prasimix]

Unfortunately this will require deeper digging as it is not supported in HAL.

Oh well. Nevertheless, the mouse implementation is great. It's the small touches one wouldn't otherwise think about, such as needing a button press and mouse move to exit standby.

Reported as #121.

[prasimix]

Is it OK to set, say, one channel to 4V and the other to 5V and then connect them together?

I am exercising a battery charger, so have one channel pretending to be USB at 5V and the other pretending to be the battery at 4V. It is currently working (albeit with the 4V channel not sinking current), but when I first set up I got a consisten situation where a channel could be unconnected (that is, no physical connection to anything) yet show the correct V out on the display with the green LED lit but no actual output (i.e. a voltmeter shows 0V). No overcurrent or anything untoward, just no output.

Naturally, I can't replicate it now and the log showed nothing unexpected. So I wondered if I might've tripped something that disabled the outputs (it happened on both channels, separately, and I think a mains power cycle fixed it but I can't be sure - wasn't taking notes and now I am it's not happening...)

Not really understand what is the idea behind connecting two outputs with different voltages, I assume, in parallel. The DCP405 can "fake" the battery so that it sinks up to 1 W if the DP is active (default state), and this too will be interrupted very quickly by the firmware. With the DCM220 this should not be tried at all. For proper battery simulation (charging/discharging or sourcing/sinking) we need 2-quadrant DC power module that is still in roadmap.

[Kleinstein]

Applying an external higher voltage can trip the over-voltage protection. Depending on the settings this can set the modules in the standby mode (output off). I would expect a message in the log than.

Ideally a moderate external voltage (e.g. within the range of the supply) should not cause damage. Usually it is not so difficult to handle - if the DCM220 can not tolerate, fixing this would be a point high on the wishlist.
With a higher voltage (e.g. 40 V to the 24 V regulator) this could be more tricky.

EDIT:
The DCM220 has a direct synchronous switched mode regulator at the output. So it would behave like a near short (inductors + FET switched to ground) to an external voltage. For this kind of circuit I see not simple fix.

[PlainName]

Reported as #121.

Thanks

But... I was pointing out that it already uses click+move to exit standby, and I was surprised. Hmmm, if you weren't aware of that perhaps it's my mouse. Could be worth a fortune on Ebay...

[PlainName]

Not really understand what is the idea behind connecting two outputs with different voltages, I assume, in parallel.

Yes, in parallel. In the project, USB power is used to charge the battery. Normally the device runs off battery but I need to check charging, obvioulsy. At that point both outputs are connected via the charge chip (which current limits) so they're not directly connected but one is driving the other.

Edit: worth mentioning that the charge chip reduces the USB 5V to ~4V, so there is about 100mV going into the channel set to 4V.

The DCP405 can "fake" the battery so that it sinks up to 1 W if the DP is active (default state), and this too will be interrupted very quickly by the firmware.

Maybe it was that, but wouldn't there be some message to that effect? I wasn't looking at simulating the charging aspect, BTW - I and checking that the USB power will successfully take over powering the device, and then that the battery will sustain operation when the USB is disconnected, so I'm just interested in pushing power rather than sinking at the moment.

I had thought I'd got the leads mixed up - negative from one with positive from the other. That would give the effect I had, except that I had one part working and the other not. I think if it was a lead mixup neither would work.

Trying it again just now it's fine. I think it might be safe to put this down to some kind of user error.

[PlainName]

Applying an external higher voltage can trip the over-voltage protection.

Good point! And I have OVP turned on. But I don't see any tripping cause by a higher (albeit in mV) voltage being pushed in. The channel current output is nothing, but if I remove the external power the channel instantly springs back to life.

The DCM220 has a direct synchronous switched mode regulator at the output. So it would behave like a near short

Eek! But fortunately they are DCP405s. I guess a blocking diode in the lead wouldn't go amiss though.

[prasimix]

Applying an external higher voltage can trip the over-voltage protection.

Good point! And I have OVP turned on. But I don't see any tripping cause by a higher (albeit in mV) voltage being pushed in. The channel current output is nothing, but if I remove the external power the channel instantly springs back to life.

 
I'd recommend that before such experiments you become familiar with the possibilities. This can avoid unnecessary frustrations, waste of time as well as giving a wrong picture of BB3, i.e. that some things are not working properly. The DCP405 has two OVP modes: hardware and software. The first is very fast and the trip level is set relatively (about 3% above the set output voltage), and the second is significantly slower and is set as an absolute value. Furthermore, the DCP405 has a down-programmer which when turned on will try to "consume" the difference of the output potential, so in case the external source cannot source a large current it will manage to maintain the set output voltage.

[PlainName]

This can avoid unnecessary frustrations, waste of time as well as giving a wrong picture of BB3

Yes. Which, of course, I don't want to do. That isn't what was happening here, though.

[exe]

On dcp405 there is a post-reg, which is using bjts. Those will probably not liking reverse bias. So, I wouldn't apply voltage to output terminals. I'm also not sure how pre-reg would like that.

Technically, pre-reg is +4.5V above output, and bjts usually specified to withstand ~5V of reverse bias (a little bit more). So, applying up to +4V to current output might be fine, but I'd still avoid that.

[PlainName]

OK. I allowed it because a previous post here suggested it was fine (in that one I think they used one channel as sink and the other as source). Current limit is also minimal, so we are not talking  Photonicinduction-type videos here 

[exe]

Photonicinduction-type videos here 

Well, I have three dcp405, that could give up to 120V@5A. So, I guess, some sparks can be made, but I don't dare. 120V DC sounds lethal to me.

Or, one can try 40V@15A if connecting all outputs in parallel. Together with some capacitor that can give quite some sparks. Still not on par with Photonicinduction, but quite something.

[prasimix]

I don't know what effect this can have, but I'll mention it: you've probably seen a link to TrustPilot on the kit assembly instructions page.
Thanks in advance to everyone who used it to leave a review: https://uk.trustpilot.com/evaluate/www.envox.hr?utm_medium=trustbox&utm_source=TrustBoxReviewCollector

[prasimix]

Bunnie just wrote the following: https://uk.trustpilot.com/users/5fe9cc3ef2bbba0019666fcf

Open source hardware at its best

Open source hardware at its best - outperforms closed source solutions, and not only are the schematics shared there's a site with detailed explanations and discussion about the various elements built into the supplies. I loved being able to read about the curious 1.1uH spiral PCB inductor on the back side of the OVP triac!

Really enjoyed building my unit, and just starting to use it. The new firmware seems really rich in features and it does much more than I thought it could at first. Building it was fun and didn't take too long, the only tricky bit was installing the power supply interface cards into the headers. It's hard to get a visual on the alignment, but I could slip my phone into a gap between the cards to inspect the final assembly and make sure I didn't get it wrong. Everything came right up and worked the first time through. It was also great that the units came pre-calibrated this time!

[Rerouter]

Finally had a chance to build my BB3, found out the ribbon cable between the PSU and the MCU board had the plug on the MCU side rotated 180 degrees,

I have since corrected the connector, but Its throwing 2 errors and the touch screen is not responding,

The 2 errors
- EEPROM Write Error on MCU
- Failed to save configuration block

To me this points to an issue with the I2C bus that runs common between the MCU, the touchscreen IC, the EEPROM, and a run to the aux power supply, is there any way to narrow down the problem space with this info, as it seems odd that there is no error about the AUX PSU, when it has I2C running to it,

[prasimix]

Do you have any possibility to power MCU with external 5 V? In that way you could remove possibly faulty 16-pin IDC cable from the list of suspects. EEPROM Write Error on MCU means that something is wrong on I2C bus that goes over that cable.

[Rerouter]

Powered like that, no luck, if I'm reading things right, there is a chance 12V was driven into SCL / SDA, will lift chips and have to hope the eerpom or touch screen IC sacrificed itself, rather than the ARM I2C pins,

[prasimix]

Powered like that, no luck, if I'm reading things right, there is a chance 12V was driven into SCL / SDA, will lift chips and have to hope the eerpom or touch screen IC sacrificed itself, rather than the ARM I2C pins,

If 12 V came to I2C then MCU module is probably ready to be replaced. Could you send me a picture of 16-pin IDC cable?

[Rerouter]

Here is how it arrived,

[prasimix]

Ouch, that explains everything. Please send me by PM your shipping address for a new MCU module.