Does that help? I don’t have the chance to connect to the notecard right now.
The S7V8F3 is not rated to provide 2A, do you think it will work still? Or do you mean the 9V setup with S13V30F5? I tried that one powering both notrcarrier and MCU (vin, so won’t be same regulated 3v3 anyway). I have gathered Gnd for both voltage levels.
Unfortunately, the piece of information I need is the SKU:
"sku": "NOTE-NBGL-500",
The 2A comes as a burst, and not a sustained draw. I will check against the datasheet and then test it against my regulator with my Notecard. However, before I power profile it, I want to ensure we have the same SKU of the Notecard.
This graph gives me hope. The orange line (4.8V) looks like it extends out to nearly 2A, so I’m hoping a burst won’t hurt it.
Best,
Zak
Good I’ll try that, but might have to use higher battery voltage to stay above 4.5V for longer. Will get the rest of the information on Monday. the card says 1.5 on the PCB, and should be nbgl.
I will also try to use the Swan as host to see if there is something going on with the Artemis, it’s out of stock anyway now.
In the picture you have the tiny dip switch on Notecarrier-B set to 1V8 instead of 3V3.
Can you try flipping the switch and see to 3V3 and see if it behaves better?
~Zak
Oh, didn’t even know about that one! Will try tomorrow 
Good catch!
I think the dip switch was already at 3V3. It is set fully in that direction.
Using the 3V3 supply to V+ on notecarrier causes the power led on MCU to fade intermittently. New lock up occured.
Edit: modem didn’t manage to connect for over an hour, reverted to modem hooked up to battery. Immediately connects.
{
"body": {
"org": "Blues Wireless",
"product": "Notecard",
"version": "notecard-3.2.1",
"ver_major": 3,
"ver_minor": 2,
"ver_patch": 1,
"ver_build": 13982,
"built": "Feb 3 2022 15:02:36"
},
"version": "notecard-3.2.1.13982",
"device": "dev:867730051260788",
"name": "Blues Wireless Notecard",
"sku": "NOTE-NBGL-500",
"board": "1.11",
"api": 3
}
I noticed that the voltage on Vio is varying between 3 and even up to 4.2V, fluctuating a fair bit, especially during transmission. I tried forcing it with the host MCU, but it does not manage to keep it low. This is potentially damaging to the MCU.
Since you are experiencing swings in voltage, it may make sense to improve your wires and batteries to support larger current draws – such as those which result from initializing the cellular modem.
Instead of using jumper wires to power the solution which are often a very small gauge (22-24AWG), you could use a larger gauge wire (18AWG) that is rated for 2A, and solder the connections directly to a 2A compatible header on a protoboard.
Although it is common place in many consumer products, putting three batteries in series is not good for high-current draw applications. If a given battery chemistry cannot sustain the current draw of the application, then the polarity of the middle battery will reverse temporarily to compensate, which in turn will compromise the battery as well as the available power.
Let’s first rule out the power supply as the issue, before we move on to investigating other potential problems.
Sincerely,
Zak
Hi Zak,
first: Thanks a lot for the help and the enthusiasm in getting this worked out! That makes all the difference! I am very optimistic that the main hurdles are out of the way by this point.
This seems to be correct! I have wired the project up as directly as I could at this point, and the swinging voltages are all gone and I do not observe any brown-outs anymore! Hurrah! I must have been using low-current jumper-wires, measuring in total several ohms between power supply and notecard: obvisouly causing a significant voltage difference during current bursts. Would never have thought about this.
I was not aware! Today I have been testing with NiMH-batteries (GP Recyko 5700 mAh, rechargeable) and it has worked flawlessly. These should be able to sustain the current - but for alkalines it is a different story. Do you think I could use alkalines if I put in a couple of super-capacitors in parallel with the batteries (e.g. eqv. of 5F)?
In addition to the power-supply I updated my rust-driver with the same delays as in note-c. Once I did that I stopped getting I2C errors from the notecard.
In summary, it seems at this point that it were two main issues:
Once I set this up it still manages to transmit 8kB over I2C in maybe a couple of seconds, at my current sample rate I need to do that every 20 seconds. And transmitting (syncing) a 50% full notecard worth of data to the notehub takes about 4 minutes. That is equivalent to about 30 minutes of recording at the current sample rate. So lots of margin still!
Have a nice weekend!
– gaute
That is wonderful news!
It was great to work with you, and thank you for your patience and dedication! I have already updated the documentation to indicate a delay should be added between I2C chunks, to ensure no one else need stumble over this issue again.
Cheers,
Zak
Hi again,
Using NiMH batteries seems to do the trick. Alkaline has so far not been able to supply the current, but maybe I can solder that better. Probably depends a lot on the exact brand and type.
I noticed that if I try to send large packages during sync there is an error, and I can usually work around this by just waiting until the sync is done. Right now I am checking whether the requested field is set in the response to hub.sync_status. Will this also be set when a automatic, periodic, sync is initiated? What is the most reliable way to determine whether a sync is currently ongoing or requested?
Thanks, Gaute
I would use the completed parameter (from a hub.sync.status request) as it tells you the number of seconds since the last sync was completed.
So if the completed field is present in hub.sync_status I can transmit? It is reset when a new sync is initiated? Won’t it be unset on startup?
This is how it looks after a completed sync:
SyncStatus { status: None, time: Some(1647526509), sync: Some(true), completed: Some(225), requested: None }
One way to determine if the Notecard is actively syncing data with Notehub is to check if the completed and time parameters are absent from a hub.sync.status response (those values are reset to 0 when a sync starts and populated when it finishes).
Thanks, that should work when at least one sync has been completed. But on notecard startup these will probably also be 0, even though the card is not syncing?
That’s a good point and partially correct. When a Notecard first boots, it’s going to attempt a sync immediately (unless the hub.set mode is “off”). You also need to be aware that if there is a failure syncing data for some reason, those parameters will remain at 0. We’re going to talk about this situation more internally and get back to you with more info next week.