Custom Data Logger / Test Automation Project

[seanEE]

Hello everyone -
I’m a hardware / software engineer and I mostly work on IOT medical devices for small companies / startups.

When testing my prototype devices, I found I spent too much time setting up test equipment to acquire basic data. I made my own data acquisition device – totally focusing on ease of use – to fix that.

https://trendeca.com/

I’m at the stage now where I’m looking for a bit of feedback. I made a small batch of Beta devices to share with my fellow engineers. Contact me at info@trendeca.com if your interested in getting one. We’ll find a price that works for you (probably just pay for the parts).

Cheers,
Sean

[Rerouter]

I will say the thought of "IOT medical devices" being a field of profession will probably haunt me for the next few days.

Things I was not able to find from the data sheet:
- Does the device include an RTC and is time / date stored on the CSV file.
- Is it manual Start / Stop or can you do conditional recording, e.g. V1 > 0.77V
- How can the outputs be used, can it be conditional, or is it manual.
- Can the wifi be disabled in the settings (radio fully off)
- Can the fuses be easily replaced
- Can the screen be switched off / Auto off after X time
- Can the device be user Calibrated

[beanflying]

So what has changed since we did this for you last year on your product? 

[seanEE]

Rerouter-
Thanks for the feedback and comments!

Regarding the “medical devices” - please don’t worry - I’m not connecting anybody’s pace maker to the internet . I mostly work on products where connectivity is an essential feature– an emergency alarm product to call a help centre for example.

A few answers to your questions:
-No, the device does not have an RTC. Every test begins at time “0”, time increments are then recorded in the CSV file.
-There is no battery inside the product at present. It is powered via an AC/DC wall wart. A screw terminal is also provided such that the user can power the product from an external battery. The product generally draws 6W.
-Data recording and outputs are presently manual (via touch screen interface or wifi connectivity). It would be a simple software change to introduce conditional actions if that was important. I have also thought about developing an “API” for the device so the user would have total control – what do you think?
-Yes, we can make the radio go away for good if that is important
-The fuses are PTC – they reset themselves after the fault is cleared.
-Yes, the screen can be set to turn off after a certain time – Presently, I have it set to stay on all the time though. It is an easy software change to make this user configurable if that is important.
-Presently, I perform the calibration when I assemble the device. It would be fairly easy to allow users to cal the device though – I would probably just have to publish an app note on how it is done.

Feel free to flick me an email if you’d like to talk more about Trendeca (or med devices for that matter

Cheers.

[seanEE]

Beanflying-

Wow! Good memory – Yes, I guess I have been working on this thing for over a year now.

Here’s what’s been going on:
-Early feedback suggested people wanted a major price reduction. I did a major re-design and was able to get the BOM cost down by roughly 10x.
-Got a software driver working for the temperature measurement circuitry – acquisition rate is much higher now.
-Local testing. Trendeca has helped to design a couple of new products that have been recently launched on the market.
-Website is totally new, it also has some nice case studies data now.

[Rerouter]

A few answers to your questions:
-No, the device does not have an RTC. Every test begins at time “0”, time increments are then recorded in the CSV file.
-Data recording and outputs are presently manual (via touch screen interface or wifi connectivity). It would be a simple software change to introduce conditional actions if that was important. I have also thought about developing an “API” for the device so the user would have total control – what do you think?
-Yes, we can make the radio go away for good if that is important

For the time, If you don't have an RTC, perhaps look if you can use an internal timer, with the ability to set the time, timestamps really help when you come back to data later on. even if its only the start and end times.

The conditionals thing just comes down to the "Bodge" factor, an engineer will generally try and abuse every tool he has his hands on to accomplish tasks, e.g. Ok, you have had this device hooked up for the past 10 days, at a glance can you see when something went wrong, etc, anything to narrow it down, how many times did it go wrong, how badly it went wrong, Ideally without having to pull out a computer or phone, as it has its own UI

E.g. with conditionals, every time the device your monitoring gets to hot you short the devices reset line to ground with an Output, As someone who has used the trigger out of an oscilloscope to act as a temperature controller for a week until the new part arrived, Letting the device be used without any other devices, and be reliable enough to trust to leave for weeks at a time, can make it convenient enough that people will keep it with them as a get out of strife tool,

The radio off thing is both a power and a location thing, If your running it off batteries, having the wifi and screen off on a device like this I would imagine should reduce the power to at least under 600mW, glad to hear it can be powered off a battery, What voltage range can the battery be, As "12V" to some means car battery which may actually be more like "14.2V" while charging.

[beanflying]

I see the pricing has now gone from the site too

I have a job that I was going to do from scratch for a 3D printer enclosure (ex fridge) as per the photo in the next month or two. Couple of Fans to be controlled and 2-3 thermocouples to monitor the gradient in the enclosure (I was going to use RTD's but I see you still haven't added support). The enviro controls aren't more than plus or minus a few degrees critical so your logger/Type K's would more than cope in this case. I have another printer in a separate enclosure too and in a quick glance and it seems like there is enough channels to run it too. Also additionally remote power kill for each printer depending on Channels should it catch fire via the SSR. Think that's most of the channels used 

Do you have a link you can send me for the software to have a look over so I can get an idea on how it runs? Consider me interested as it will save me a chunk of time which I don't have 

Drop me a PM if you like.

[sokoloff]

Are you sure your burden voltage spec is correct on the milliamperes measurement? The datasheet says 75 mV/mA which is certainly uncompetitive but borders on utterly useless. Are you sure it’s not 75 μV/mA? (Even that isn’t a particularly impressive spec, but is at least usable for coarse measurements of low average power, moderate burst power battery devices.)

I didn’t see the prior round of feedback, but for me being able to drive the device with an API a would be desirable. (As would an RTC, but a API lets me add the clock function on my own equipment as a workaround.)

Email coming in hopes the datasheet has an off-by-1000 error in that key spec. Good luck! 

[seanEE]

Rerouter-

Thank you for the suggestions!

The acceptable range for the external battery supply is 11V to 16V.

[seanEE]

Sokoloff-
Thanks for the comments!

An explanation on how the uA/mA measurement channel works:

I wanted to make a measurement channel that was capable of measuring uA sleep state currents on battery powered devices, but also measured higher (up to 2A) currents. I did this by introducing two different burden voltages.

For currents <1mA, the burden voltage is 75mV/mA. For example:
A 3.7V lithium battery powered device has a sleep state current of 175uA. The voltage drop due to the measurement equipment is 13.1mv (the device under test receives 3.6869V).

For currents >1mA, the burden voltage is 0.15V/A. For example:
The above battery powered device has a “high power” feature it turns on and the current draw is now 138mA. The voltage drop due to the measurement equipment is now .0207V (the device under test receives 3.6793V).

How do we ensure the device under test does not “brown out” when Trendeca switches between the two burden voltages? I have implemented a current detection and switching circuit purely in solid state hardware so it acts extremely quickly.

During recent testing, this measurement channel was used to find an interesting bug with an “ultra low power” device. The sleep state current for the device was observed to be roughly ~80uAs, but the battery appeared to keep going flat after only a few days. After using Trendeca to profile the battery current over a 24 hour period, it was discovered that a “high current” feature was being turned on for 40 seconds every 4.5 hours – a simple firmware fix and the bug was sorted.

[seanEE]

Beanfly-

Sounds like a cool project! Thanks for your email -I’ll get back to you shortly.

[sokoloff]

Ah, so you're auto-switching between two shunt resistors (or shorting one of them). Makes sense and means the worst case burden point is 75mV right at 1mA before the switching happens. The auto-switching function wasn't clear to me; I assumed I was forced to setup one or the other (to avoid the brownout issue as you mention.)

My apologies: I was reading the spec sheet on my mini iPad and must have misread the higher range as 150mV/mA rather than 150mV/A, so the off-by-1000 error was my own.