Regarding “Starnote” satellite detection - I’m having issues consistently accessing satellites for a Noteadd. My location is not ideal but I can “sometimes” push a payload & have it indicate (via Notehub) the transaction was via Satellite. I’ve defined a Template for the desired fields - Notehub displays those fields properly – but the transport is “Cell” vs “Sat”.
Using the “Trace on” capability in your “Browser”, are there diagnostics that would indicate why “Cell” was chosen and not “Sat” (i.e. ‘weak’ signal)? This behavior may be due to my location – I’m just looking to make sure my program is working properly.
Here’s the Trace dump – notice the “method”,”cell” below .. is that forcing the “cell” transport?
"mode" is not a valid argument for the card.transport request ("method" is). Given that, the {“method”:“cell”,“crc”:“0004:F79210C3”} response is telling you is that your Notecard is currently configured to communicate over cellular only. You’ll want to use {"req":"card.transport","method":"ntn"} if you want to try connecting to the satellite network directly, or {"req":"card.transport","method":"cell-ntn"} if you want to use cellular with a satellite fallback.
To answer your broader question though: we have a documentation page on the algorithm that Notecard uses for falling back from cellular / wifi to NTN here: Connection Retry and Fallback Behaviors Essentially, Notecard will attempt to connect to a cellular network twice, and if those both fail it’ll fall back to attempting a satellite connection.
Notecard doesn’t send diagnostics on why it picked cell vs. satellite, unfortunately. We do, however, have a few different ways you can measure your cellular signal strength, which should give you a pretty good idea of how good your cellular coverage is Diagnosing Cellular Connectivity Issues
Unless you’re testing in a very rural area I’d be surprised if Notecard is falling back to satellite on its own. My guess is this has more to do with configuration.
Let me know if this is helpful and if you have any other questions.
Your response via the “mode” argument fixed the problem .. I can now add notes to Notehub via satellites (yeah)
My next question is probably a bit more involved – I’m attempting to use the Notecard’s internal GPS engine – I set up access to be “periodic” on a 60 second interval. No luck yet .. your forum has a number of entries related to the subject so my thought was to wade through them first before posting any questions.
I did have one question – does the GPS acquisition happen in the background? My program pauses until a button is tapped .. I then acquire the GPS position & post a note to Notehub and then wait for next button hit. Does this behavior not allow a GPS fix to occur? (i.e. not giving the engine enough time to acquire the fix)
My next question is probably a bit more involved – I’m attempting to use the Notecard’s internal GPS engine – I set up access to be “periodic” on a 60 second interval. No luck yet .. your forum has a number of entries related to the subject so my thought was to wade through them first before posting any questions.
The main thing I’m curious about is whether you’re getting back anything useful from the card.location request. When I try this out myself I typically just spam {"req":"card.location"} to see what’s happening.
The tracelog can also be useful. If you run trace +gps you can get some extra noisy logging.
I did have one question – does the GPS acquisition happen in the background? My program pauses until a button is tapped .. I then acquire the GPS position & post a note to Notehub and then wait for next button hit. Does this behavior not allow a GPS fix to occur? (i.e. not giving the engine enough time to acquire the fix)
Yes, GPS acquisition happens in the background. A couple things to know though:
Notecard’s cellular modem and GPS module cannot be used at the same time, so if, for example, a sync is happening, Notecard will wait for the sync to finish before attempting to get a GPS fix.
Notecard only gets a new GPS location if the device has moved (as detected by its onboard accelerometer). Notecard does this to avoid wasting power to get a location that hasn’t changed.
Setting "seconds" to 60 is pretty aggressive, as realistically Notecard won’t be able to make a fix every minute, especially if it’s managing other tasks. We recommend setting seconds to a maximum of 300 to give Notecard time to schedule syncs, etc.
Because Notecard handles getting a location in the background (and stores it in its flash and returns it from the card.location request), in a production scenario you should be fine to just perform a hub.sync when your button gets pressed. Notecard will send its last-known location to Notehub, and Notehub will append it to your events.
If it’s mission critical that Notecard get a new location and sync that as soon as possible, we have a section in our docs that shows off a workflow you can use for that Asset Tracking with GPS - IoT Connectivity at Blues.