Author Topic: Getting serial data  (Read 547 times)

detz

  • Newbie
  • *
  • Posts: 12
Getting serial data
« on: February 07, 2019, 09:58:14 AM »
I've never graphed serial data from the arduino IDE but would love to with the ranger I should be getting today. My primary use case it to map power usage over time for battery devices so ideally I would like to hook it up for days and collect the data which I can graph and analyze. Is there a better way to do this? Maybe connect it to a pi and just have it log out all the serial data?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5917
  • Country: us
    • LowPowerLab
Re: Getting serial data
« Reply #1 on: February 07, 2019, 12:50:34 PM »
You know ... after feedback from many users, I almost want to drop the BT idea, or just leave the header there if people still want that option, but actually offer an RFM69 logger - that can log plenty fast for user analysis (30 times a second with some lost packet tolerance good enough?).

I imagine in some cases the serial output is useful to capture events "of interest", meaning it would be great to see only data that really matters rather than a ton of data that is just linear. Kinda like deep memory with trigger on a scope which can log a very long time window but only give you what you care about. You probably dont care that your device is sleeping at 10uA for 3 days, but you care more about what happens when it wakes up, how often, and what the spikes are. Lots of coding to make all that happen but thats why this device is programmable by you - the user. The really great suggestions and contributions have a great chance to make it into a future revision.

Another idea for external logging is to have optically isolated outputs - in which case no BT module is needed - that would be nice to have on USB but then that would only work for logging and not charging so a little tricky to make happen, and ... more expensive :P

detz

  • Newbie
  • *
  • Posts: 12
Re: Getting serial data
« Reply #2 on: February 07, 2019, 02:05:42 PM »
Hmm, RF would be interesting. Triggers would be nice too, I see no reason why the last n events couldn't be stored and if a trigger happens send the last n events and all new ones until the trigger stops. It's easy to filter this out on the receiving side too, my initial plan since I don't physically have the unit yet was to have a python script capture all data and just store it then have other scripts filter and output what I'm interested in. I might just make that initial scripts drop anything that is below my baseline to save space.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5917
  • Country: us
    • LowPowerLab
Re: Getting serial data
« Reply #3 on: February 07, 2019, 02:26:24 PM »
With the current basic logging (all data) you can probably get going quickly with your python approach.
The firmware itself can be made to trigger at whatever conditions you want.

detz

  • Newbie
  • *
  • Posts: 12
Re: Getting serial data
« Reply #4 on: March 20, 2019, 01:13:19 PM »
Finally need to measure (track) current so I want to try this out. Since the header was made for BLE should I do anything different if connecting it directly to serial/usb? I'm assuming I should just connect tx/rx and gnd and leave the 3.3 floating? Using any normal UART connector should work fine too?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5917
  • Country: us
    • LowPowerLab
Re: Getting serial data
« Reply #5 on: March 20, 2019, 02:01:00 PM »
It shares a ground with the rest of the board.
You asking the questions you just did, makes me wonder if you read the safety use page: https://lowpowerlab.com/guide/currentranger/safety-and-proper-usage/
If you choose to attach a mains referenced GND to that BT header GND, make sure nothing else mains referenced is attached to the CR. Your DUT should be completely floating (ex battery powered) and the output should at most also be connected to a floating DMM, not to a mains powered scope. Or you will smoke it.
I also suggest using a USB isolator that's available for cheap, if you want to do logging over the native USB interface. That's basically better than fiddling with headers and ensures you wont do damage.

detz

  • Newbie
  • *
  • Posts: 12
Re: Getting serial data
« Reply #6 on: March 20, 2019, 05:01:51 PM »
Right, it would be usb from computer (mains gnd), wall adapter* to power the device. Since I'll be recording via serial/usb I won't need anything connected to the scope side. That will be fine, right?

*Adapter is a two prong typical "wall wort" device which should be isolated.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5917
  • Country: us
    • LowPowerLab
Re: Getting serial data
« Reply #7 on: March 20, 2019, 05:19:53 PM »
Right, it would be usb from computer (mains gnd), wall adapter* to power the device.
Are you sure you read that page?  :)

*Adapter is a two prong typical "wall wort" device which should be isolated.
Should be isolated?
That's a recipe for disaster.


detz

  • Newbie
  • *
  • Posts: 12
Re: Getting serial data
« Reply #8 on: March 20, 2019, 06:06:14 PM »
I've read your page, and various articles online, it's still confusing.  :(

I watched a video by Dave Jones where he stated as long as it doesn't have a ground pin it should be isolated, so most wall worts power adapters are okay. Guess I should just get a usb isolated to be sure.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5917
  • Country: us
    • LowPowerLab
Re: Getting serial data
« Reply #9 on: March 21, 2019, 08:54:00 AM »
The neutral is connected to earth ground in your panel, that is electrical code.
So take online videos with a (big) grain of salt ;)
Isolation is key depending on what you do. As I say in the guide, you can have up to 1 earth ground connection to the CR (either the USB, input or output). Any other connections that in some way are galvanically connected to earth mains, (or the same source of current flow) and your CR can be damaged. That is simply ohms law, current flows between different electrical potentials.