skyBlip builds open-source electronic conspicuity equipment for general aviation. The devices transmit and receive ADS-L 4 SRD-860 air-to-air, receive the ADS-L traffic uplink from ground stations, and receive FLARM-generation traffic. Under ADS-L.4.SRD860.F.2.2 we apply for one manufacturer page of the Address Mapping Table and a unique 8-bit manufacturer prefix, so that a skyBlip leaves production with an address drawn from a range that is ours.
This page is what accompanies the application to registry@ads-l.aero: who is applying, what the equipment does on the air, how we intend to use the range, and one question we would like the registry’s view on.
| Applicant | François Catuhe, France — skyBlip |
|---|---|
| Site | skyblip.eu |
| Sources | github.com/fcatuhe/skyblip — firmware GPL-3.0-only |
| Specification implemented | ADS-L 4 SRD-860 Issue 2, ED Decision 2022/024/R |
The firmware is public, so every claim below can be read rather than
trusted: the address logic is one file, core/settings/address.cpp,
and the wire format another, core/protocol/adsl.cpp. The host
test suite generates a behavior index,
docs/BEHAVIOR.md,
which lists what the firmware is checked to do and is regenerated from the
tests themselves.
| Device | Transmits | Receives | Status |
|---|---|---|---|
| skyBlip Go | ADS-L Traffic, M-band | ADS-L Traffic, ADS-L Traffic Uplink, FLARM-generation traffic | flying, firmware published |
| skyBlip Panel | ADS-L Traffic, M-band | as above, output to the panel display over RS-232, Bluetooth and WiFi | in development |
| skyPost Helio | ADS-L Traffic Uplink, O-band HDR | ADS-L, FLARM-generation traffic, ADS-B 1090 | in development |
| skyPost Bridge | ADS-L Traffic Uplink, O-band HDR | from an existing receiving station (OGN, PiAware) | in development |
FLARM-generation traffic is decoded and shown to the pilot. It is never re-transmitted: an airborne skyBlip transmits its own position and nothing else, and the uplink is a ground station function.
| M-band channels | 868.2 and 868.4 MHz, alternating by UTC second (§C.2, §C.2.5) |
|---|---|
| O-band HDR | 869.525 MHz, uplink slot (§C.4, §C.5) |
| Transmit power | +14 dBm e.r.p., the ERC 70-03 band h1.4 and EN 300 220 ceiling |
| Duty cycle | 1 % of any hour, metered on the device; one 5 ms burst per second is about half of it |
| Transmitted payload | Traffic (type 2), 1 Hz airborne, 0.1 Hz on the ground (§G.1.16) |
| Receive dwells | 400 ms on each M-band channel and 190 ms on the uplink slot, one SX1262; M-band receive is declared Partial under §G.2.2, a single radio cannot hold both channels at once |
| Design assurance | none claimed: the payload carries DAL 0 |
Not implemented yet: the Status payload (type 3). It is the next protocol work, and the declaration of conformity will follow it rather than precede it.
Today a skyBlip has no range to draw from, so it mints its own: the 24-bit address is derived from the MCU serial number and transmitted under an AMT entry in the self-minted group, 0 to 4. Because that space is shared with every other tracker that derives its identity the same way, the device moves off the prefixes known to be crowded — 0xD0, 0xDD to 0xDF and 0x11 — and refuses the two addresses that mean “none” and “dead SPI read”, 0x000000 and 0xFFFFFF.
With an assigned page and prefix, that guesswork ends. We would allocate the 16-bit base address space densely from one end, one address per unit recorded at production, and apply for a further page and prefix combination once the range is used up, as F.2.2 requires.
The two other address paths of the specification stay as written. An ICAO address (AMT 5, F.2.3) is a user setting and, where an aircraft has a Mode-S code, the preferred one: it is transmitted exactly as issued, and the manufacturer address is not used while it is set. Privacy mode (F.2.4) selects AMT entry 0, and in the same mode the vertical rate is transmitted as unavailable rather than as zero, which would claim level flight.
In VFR the identity everyone uses — the pilot on the radio, the club, the EFB, the field — is the registration: F-GXXX on a certified aircraft, an F-J callsign on a French microlight. It belongs to the aircraft for its life. It is not a per-flight item like an airline flight number, and a receiver that could show it would be showing the traffic the way a pilot already thinks about it.
Issue 2 carries no field for it. The Traffic payload (G.1) has none, the Status payload (G.2) has none, and the only identity on the air is the 30-bit sender address of F.2.2: 6 bits of AMT and 24 bits of address. Where the aircraft has a Mode-S code the ICAO address closes the gap, since a national registry resolves it to a registration, and F.2.3 is right to prefer it. That path is closed for most of the traffic this equipment addresses: a French microlight has no ICAO 24-bit address, nor has a paraglider or a paramotor, and under a manufacturer prefix its address is ours rather than the aircraft’s.
So we would like the registry’s view on which of the two answers it intends, because we would rather implement the one that becomes the standard:
| Answer | What it would take |
|---|---|
| A published address-to-registration database | the way the OGN device database resolves FLARM and OGN addresses today. We would publish our assigned range, let owners bind their address to their registration, and expose the mapping under an open license. |
| A callsign payload | a low-rate broadcast payload carrying the registration, transmitted every few seconds rather than every second. A new payload type has to be approved by the governing body (F.2.5), which is why this is a question to the registry and not a proposal we would ship on our own. |
Either is a small amount of work here. Neither is worth doing twice, and a manufacturer that invents its own answer is how a standard stops being one.