Scheduling Details¶
Overview¶
Jetpack operates on a repeating basic schedule.
The Jetpack schedule is:
- Get GPS lock (which also tells you the time)
- At start minute:
- Transmit Regular Message
- At +2 min:
- Transmit Basic Telemetry Message
- [Repeat]
This is a repeating 10-minute window, with 5 time slots of 2 minutes apiece.
You can visualize this schedule as follows:
| Mode | Start minute (Slot 1) |
+ 2 min (Slot 2) |
+ 4 min (Slot 3) |
+ 6 min (Slot 4) |
+ 8 min (Slot 5) |
|---|---|---|---|---|---|
| Default | Regular | Basic Telemetry |
With Copilot Control, this schedule of tasks can be substantially modified and enhanced by you.
Custom Messages¶
You can send your own Custom Messages in any slot.
JavaScript controls this.
You can send a Custom Message in any combination of the indicated slots.
| Mode | Start minute (Slot 1) |
+ 2 min (Slot 2) |
+ 4 min (Slot 3) |
+ 6 min (Slot 4) |
+ 8 min (Slot 5) |
|---|---|---|---|---|---|
| Default | Regular | Basic Telemetry | |||
| Copilot | Regular -or-Custom Message |
Basic Telemetry -or-Custom Message |
Custom Message |
Custom Message |
Custom Message |
Custom Actions¶
You can perform Custom Actions in any slot by using JavaScript to control the tracker hardware and IO.
This can be communicating with sensors via I2C, controlling devices via GPIO, and so on.
JavaScript controls this.
Custom Actions have no impact on Custom Messages or Default behavior.
| Mode | Start minute (Slot 1) |
+ 2 min (Slot 2) |
+ 4 min (Slot 3) |
+ 6 min (Slot 4) |
+ 8 min (Slot 5) |
|---|---|---|---|---|---|
| Copilot | Custom Action | Custom Action | Custom Action | Custom Action | Custom Action |
Deciding What Happens¶
Jetpack lets you decide what happens in a given slot. You can:
- Do nothing
- Run JavaScript for a Custom Message
- Run JavaScript for a Custom Action
- Run JavaScript for both
Depending what you want to do, your control may be subject to requirements and affect the behavior of the tracker in more nuanced ways.
Requirements¶
Jetpack knows you want to send a Custom Message when your JavaScript uses the Message API.
Jetpack knows you need a GPS lock to run when your JavaScript uses GPS API.
These requirements are explored more fully below in Full Description of Slot Behavior.
GPS Coasting (GPS No-Lock Scenario)¶
Jetpack can schedule activity at the right time even without a GPS time lock
Jetpack's default behavior is to wait for a GPS lock before sending any messages.
With Copilot Control, you can specify Custom Messages to be sent without a GPS lock, and Custom Actions to be taken without a GPS lock.
Why a GPS Lock is Required Anyway¶
The reason a GPS lock is required for default behavior is because of two reasons:
- Each of the two default messages require the GPS for their data content
- The GPS tells us the exact time, allowing precise synchronization with the start of the 10-minute window
Coasting¶
Coasting is the act of Jetpack using its internal clock to synchronize to each 10-minute window without a new GPS time lock.
Jetpack knows the time of day at all times, provided it ever got the GPS time ever once since it powered on.
It can do this by using its internal clock to keep track of the time that has passed since the last-known GPS time lock.
The internal clock drifts, but not by much.
The drift should be minimal and appropriate to work with provided even semi-periodic GPS time locks.
Notably, the longer the time since the last GPS lock, the more the internal clock will be off.
The precise rate of drift will depend on many factors, but include temperature and physical manufacturing conditions.
What if Jetpack gets a GPS lock picks up mid-way through a 10 minute slot
It will wait for the next 10-minute window to make use of the GPS.
Slot action in the window the lock was acquired in will be treated as having no GPS lock.
This ensures that each slot in a 10-minute window has access to the exact same (fresh) GPS data, and that GPS data isn't used in other 10-minute windows.
When would you want GPS No-Lock activity?
Maybe you're taking sensor readings that have nothing to do with the GPS.
Send your Custom Message. The receiving stations mark the data with the time of reception.
Full Description of Slot Behavior¶
Jetpack's handling of a given slot depends on a number of factors.
These include:
- Whether there is a GPS lock
- Whether the slot JavaScript uses GPS
- Whether the slot JavaScript wants to send a Custom Message
This section attempts to explain the interrelationship between these factors and what Jetpack will ultimately do.
This table represents scenarios where slot JavaScript exists.
JavaScript has to exist or only the default behavior occurs.
So, this table describes what happens when slot JavaScript exists.
If slot JavaScript doesn't parse or execute properly, the default behavior occurs.
| Tracker has GPS Lock? | JS Uses GPS? | JS Sends Message? | JS Will Run? | Message Sent? |
|---|---|---|---|---|
| No | No | No | Yes | None |
| No | No | Yes | Yes | Custom |
| No | Yes | No | No | None |
| No | Yes | Yes | No | None |
| Yes | No | No | Yes | Default (if any) |
| Yes | No | Yes | Yes | Custom |
| Yes | Yes | No | Yes | Default (if any) |
| Yes | Yes | Yes | Yes | Custom |
Copilot Control Slot Notes¶
This table shows which Copilot Control operations make most sense within each slot.
| Copilot Control | Slot 1 | Slot 2 | Slot 3 | Slot 4 | Slot 5 |
|---|---|---|---|---|---|
| Custom Message | ⛔ | ⚠️ | ✅ | ✅ | ⚠️ |
| Custom Action / Sensors | ✅ | ✅ | ✅ | ✅ | ✅ |
Slot 1¶
Custom Message
A Custom Message would replace the Regular Message.
You don't want to do this unless you really really really know what you're doing.
Custom Actions and/or sensor operations have no conflict.
Slot 2¶
Custom Message
A Custom Message would replace Basic Telemetry.
At the moment, Basic Telemetry provides much of the default telemetry provided by Jetpack.
Overriding sending this is fine, but you'll lose that Basic Telemetry (perhaps replaced by your own).
There's no way to optionally override this message, eg sometimes send Basic Telemetry and other times Custom Message (for now).
Custom Actions and/or sensor operations have no conflict.
Slot 3¶
Custom Messages have no conflict.
Custom Actions and/or sensor operations have no conflict.
Slot 4¶
Custom Messages have no conflict.
Custom Actions and/or sensor operations have no conflict.
Slot 5¶
Custom Message
A Custom Message is complex, see more below regarding timing and sequences.
Custom Actions and/or sensor operations have no conflict.
Technical Details¶
Specific Timing Sequence¶
In any given 2-minute slot, the sequence of activities Jetpack goes through looks like this:
Here we look at Slot 2, which starts with a 1m50s transmission:
Notice when the JavaScript (for Slot 3) is run.
The JavaScript for Slot 3 is actually run during Slot 2's time (in advance of Slot 3).
That is, in the period of Slot 2, after transmission, there is time to execute the JavaScript in advance of needing the resulting data for transmission in Slot 3.
Next 10-Min Window GPS Lock and Slot 5¶
Jetpack has a number of priorities to balance:
- Get a good GPS lock for the next 10-minute window
- Warmup transmitter to reduce drift
- Use minimal power
These are not always all fully possible in every situation. They can come to a head in Slot 5 in some cases.
A few factors:
- The GPS is turned off when not actively searching for a GPS lock
- To save power
- Also because the GPS can't get a lock when the Transmitter is active (interference)
- The GPS should lock quickly, but doesn't always
- Therefore it's beneficial to start looking for a lock as early as possible
- This can sometimes take 1 minute or more (sometimes much more)
- The transmitter wants to get "warmed up" by turning on 30 seconds beforehand
- This reduces frequency drift and improves reception
When Jetpack has no more messages to send in a given 10-minute window, it wants to start getting a GPS lock again so it has the maximum amount of time to lock before the start of the next 10 minute window.
Here is a visualization of the conflicting priorities Jetpack faces when there is a message to be sent in Slot 5. (This assumes a 1-minute GPS lock time window wish, but in fact Jetpack wants as much as it can get).
There is no single right answer to how to resolve these conflicts.
An experimental approach is to actually cut the WSPR transmission early in Slot 5 and letting receiving stations correct the missing bits using error correction within the WSPR protocol.
That looks like this:
In this diagram, we see, in time for the next slot:
- Transmission cut early
- A GPS lock attempt
- JavaScript run when GPS lock
- Warmup
It may not go this way.
This may result in inferior reception, or no reception, of early-cut transmissions.
There are no guarantees about timings of a GPS lock.
As a result, it is not for certain that the lock will be acquired by the start of Slot 1.
In fact, it is known to, at times, take longer than 1 minute to get a GPS lock.
See the Full Description of Slot Behavior for full implications.