Battery simulators NGM202 vs BCS6401

[Geofrey]

Hi,

I've been around here for quite some time (at least 5 years according to my own profile) but this is my first post. I usually get all the info I need and much more from existing posts, but not this time.

I design embedded products with lithium batteries, DC-DC converters, MCU and various energy sources. I am not involved in production, but I also do after sales services like diagnosis and repairs. So far I've managed reasonably fine with entry and (lower-)mid level equipment but I am looking to simplify my test setups and gain time during development, test and validation. My bench setup is currently :

-PSU : Multicomp MP710087. That's a Farnell re-badge of the Owon P4603. I found that out when I was looking for a way to 0 the current readback. It turns out even maxing out the calibration setting, the best I could get is a ~80mA dead zone, as I need to draw 81mA from the PSU for it to regulate to a 1mA setting and/or read 1mA. That's a serious inconvenience and would not recommend this PSU. I also have a couple more very basic PSUs, one linear, one switching.
-electronic load : Maynuo M9812. It has an approximately 1.6mA offset, but I am happy with this instrument
-DMM : BM789, UT191, EX330, a couple more basic ones, a couple of current clamps
-scope : DS1054Z
-time reference : Leo bodnar mini GPSDO. I am using it for RTC trimming.

So what I want my future new expensive piece of equipment to do ?
- Allow me to test hardware and software for charge and discharge at various battery/voltage level, both at stable and dynamic voltage SoC, repeatably, without spending hours getting batteries to necessary level (so yeah a battery simulator)
- Safely power up early stage prototypes at low current < 10 mA, or whatever is enough to turn on the MCU but very unlikely to damage anything
- Do the first power tests with confidence that the glitches and oscillations are not PSU induced. I spent way too much time debugging early software and hardware that turned out perfectly fine when run with batteries instead of my PSUs.
- Not worry about burden voltage or cable losses, not doing test lead swaps on powered EUT to be able to measure from A to µA when doing low power mode tests. Nor jumpstart the board with a cell and flying leads while the electronic load is connected to the battery terminals for charge tests
- Be PC controllable for automated tests, including hardware in the loop software test. Right now, due in part to long battery cycle times, doing a good (but not complete) coverage for software validation on actual hardware takes a week, running in parallel in 4 samples of each product variant.
- Last for a long time, if the equipment is good, it is likely I will keep it for 20+ years

I've narrowed down my search to the R&S NGM202 and the B&K BCS6401.
The BCS6401 can sink 10A vs 6A for NGM202 and is substantially cheaper. Both points are nice but not essential.
The NGM202 can source 12A vs 10A (I don't care at the moment), has better resolution (but not really better accuracy), seems a lot better at logging (500Ksps vs 30Ksps, 800Mo internal memory + external memory ability vs 1024 sample points), has touchscreen and eyecandy UI, a free PC software that someone here described as outdated and incomplete vs no PC software at all, but both take SCPI commands anyway.
Based on specs I am leaning towards the BC6401, but I have found 0 review, teardown or anything. I am also wondering if I would miss any of the things the NGM202 brings over. I guess the 500ksps sampling would be better to find glitches and bugs or do MCU run/sleep time analysis, but would not help with fine analysis of 100KHz switching DC-DC converter. And I should be able to add a Joulescope to the BCS6401 for even faster sampling at 2Msps and 300KHz bandwidth, at a slightly reduced accuracy. Anyway, is anyone with experience with battery simulators willing to share their thoughts and advice ? That's my first time spending that much on TE, so I am not sure what to expect.


I also considered but eliminated :
Keysight E36731A : the battery simulator part is a nearly 1000€/year PC licence. Supposing they even maintain it for 20 years that's 20k€ extra. No thanks.
Keithley 2281S : only 1A sink. I can live without the battery simulator sinking the 8A max I am doing up to now, but this is too limiting.
GW Instek PPH-1506D / PPH-1510D : 3.5A sink per channel, but only CH1 can simulate batteries so no paralleling to get higher than that, slower regulation, a bit less accurate, less expensive but not exactly cheap either, so buy cheap buy twice is not an option.

I attached a brief comparison table on the points that matters to me.

Cheers
 

[pdenisowski]

Hi Geofrey.  If you have any specific questions about the NGM, please let me know.  I've also made a couple of videos about it, and they cover battery simulation and fast logging as well.

The NGM202 can source 12A vs 10A (I don't care at the moment), has better resolution (but not really better accuracy), seems a lot better at logging (500Ksps vs 30Ksps, 800Mo internal memory + external memory ability vs 1024 sample points), has touchscreen and eyecandy UI, a free PC software that someone here described as outdated and incomplete vs no PC software at all, but both take SCPI commands anyway.

The NGM has a VNC or web based remote user interface: there's no special software for running or controlling it.  We do provide some GUI based scripts that extend the functionality of the NGM for certain special applications, but all of the base functionality is controllable remotely via a web browser or VNC client.  If there is an issue with any of the scripts, please let me know and I'll talk to the developer directly (he's very responsive to change requests).

https://www.rohde-schwarz.com/us/application/ngm200/

Obviously I'm biased towards my own company's products but having used it extensively, I do think the NGM would meet your requirements very well. 

[Geofrey]

Hi Paul, thanks for your reply.

Do you know what is the bandwidth in fast log mode ? Does fast log have an impact on the quoted accuracy numbers ? Does it add noise to the measurements ?

If I understood your video well, fastlog through SCPI sends the binary data (that's already something like 16 Mo/s of raw data I guess). How does decode to .csv works in that case ?

I noticed that every battery simulator is working on an open voltage + internal resistance model. This is good enough for most applications in the 10-95% SoC range (at least for lithium based batteries which I am the most familiar with) but on lithium cells (or at least the one we use), the voltage after stopping a complete discharge can significantly creep up for 10+ min. LiFePo can also have a more complex behavior near 100% SoC. Are there solutions for a more realistic simulation at the extremes of battery SoC ? Even if PC controlled ?

What kind of delay would be a SCPI loop for implementing a custom model ? A get latest U and I values followed by a set updated U and I targets loop, if it is not something inadvisable or risking to degrade the PSU.

I am not sure I will ever have the time to dive into these kind of things, but knowing the hardware is capable of this if the need arises would be nice.

[pdenisowski]

Do you know what is the bandwidth in fast log mode ?

I'm not completely sure what you mean by "bandwidth", but max logging rate is 500,000 samples / sec (at least that's in units of Hz  )

Does fast log have an impact on the quoted accuracy numbers ? Does it add noise to the measurements ?

No to both, at least in my experience.  I'll ask the product line if we have any numbers

If I understood your video well, fastlog through SCPI sends the binary data (that's already something like 16 Mo/s of raw data I guess). How does decode to .csv works in that case ?

If you're streaming binary FastLog data over SCPI your program will need to do the conversion to .CSV.  I can either post or PM you the format and how to convert it - it's pretty straightforward.  The other method is to do the conversion on the NGM using the built-in utility and then transfer the csv file.

I noticed that every battery simulator is working on an open voltage + internal resistance model. This is good enough for most applications in the 10-95% SoC range (at least for lithium based batteries which I am the most familiar with) but on lithium cells (or at least the one we use), the voltage after stopping a complete discharge can significantly creep up for 10+ min. LiFePo can also have a more complex behavior near 100% SoC. Are there solutions for a more realistic simulation at the extremes of battery SoC ? Even if PC controlled ?

Everything is possible via PC control   All the battery simulation control parameters and current values can be set/read via SCPI.  I'm not sure I entirely understand the scenario, but I think what you're saying is that after the battery reaches some low SoC (and is functionally "empty"), the VoC slowly moves up for a while.  In this case, I would simply use SCPI to slowly increase the power supply output voltage.  If the supply output voltage became high enough that current started flowing again (monitoring via SCPI), then I would revert to battery simulation again, either with the original model or a different "low SoC" model.  Sorry if I'm misunderstanding the question.

What kind of delay would be a SCPI loop for implementing a custom model ? A get latest U and I values followed by a set updated U and I targets loop, if it is not something inadvisable or risking to degrade the PSU.

Absolutely would not damage or degrade the PSU - lots of customers do exactly this.  I'll need to check on how quickly this can be done via SCPI, although I suspect the limitation will be the network (Eth/IP/TCP) and not the instrument.

[Geofrey]

Thanks for the detailed answers.

By bandwidth I meant like for scopes, which typically have a bandwidth lower than the sampling rate to avoid aliasing. I would like to know if fast log mode is susceptible to aliasing. Or maybe that is not applicable to the logging of a PSU, or the values logged are the average since last log point, can you clarify ?

I am pretty convinced the NGM202 is very good, now I need to decide if it 2850 € ex VAT better than the BCS6401

[pdenisowski]

By bandwidth I meant like for scopes, which typically have a bandwidth lower than the sampling rate to avoid aliasing. I would like to know if fast log mode is susceptible to aliasing. Or maybe that is not applicable to the logging of a PSU, or the values logged are the average since last log point, can you clarify ?

It's a good question:  I haven't seen power supply logging specified in terms of bandwidth - it's basically simply taking N samples per second and as long as Nyquist is being observed (and I'm sure it is), then there won't be any issues with aliasing.  In the specification sheet we specify logging rate and voltage / current measurement accuracy (which is the same as the readback accuracy), so this would necessarily include any other effects as well.

*I did some looking around and I couldn't find a benchtop power supply manufacturer who specifies logging accuracy in terms of bandwidth - most also seem to say it's the same as readback accuracy (and several don't specify it at all).