Raspberry Pi OS has yet to be updated with the latest version of Wiring Pi, so if you are using a Pi 4B then you must install Wiring Pi from source as follows:
HABPort=<port>. Opens a server socket which can have 1 client connected. Port is a raw data stream between gateway and HAB (e.g. for Telnet-like communications). Note: The corresponding functionality at the tracker end has not been published.
Longitude=<decimalposition>. These let you tell the gateway your position, for uploading to habitat, so your listener icon appears on the map in the correct position.
AFC_<n>=<Y/N>. Enables or disables automatic frequency control (retunes by the frequency error of last received packet).
mode_<n>=<mode>. Sets the "mode" for the selected LoRa module. This offers a simple way of setting the various
LoRa parameters (SF etc.) in one go. The modes are:
0 = (normal for telemetry) Explicit mode, Error coding 4:8, Bandwidth 20.8kHz, SF 11, Low data rate optimize on
1 = (normal for SSDV) Implicit mode, Error coding 4:5, Bandwidth 20.8kHz, SF 6, Low data rate optimize off
2 = (normal for repeater) Explicit mode, Error coding 4:8, Bandwidth 62.5kHz, SF 8, Low data rate optimize off
3 = (normal for fast SSDV) Explicit mode, Error coding 4:6, Bandwidth 250kHz, SF 7, Low data rate optimize off
4 = Test mode not for normal use.
5 = (normal for calling mode) Explicit mode, Error coding 4:8, Bandwidth 41.7kHz, SF 11, Low data rate optimize off
SF_<n>=<SpreadingFactor> e.g. SF_0=7
Bandwidth_<n>=<Bandwidth>. e.g. Bandwidth_0=41K7. Options are 7K8, 10K4, 15K6, 20K8, 31K25, 41K7, 62K5, 125K, 250K, 500K
Implicit_<n>=<Y/N>. e.g. Implicit_0=Y
Coding_<n>=<error_coding>. e.g. Coding_0=5 (4:5)
lowopt_<n>=<Y/N>. Enables or disables low data rate optimization.
power_<n>=<power>. This is the power setting used for uplinks. Refer to the LoRa manual for details on setting this. ** Only set values that are legal in your location (for EU see IR2030) **
UplinkTime_0=<seconds>. When to send any uplink messages, measured as seconds into each cycle.
UplinkCycle_0=<seconds>. Cycle time for uplinks. First cycle starts at 00:00:00. So for uplink time=2 and cycle=30, any transmissions will start at 2 and 32 seconds after each minute.
The program now performs some checks to determine if each selected LoRa module is present or not. If you see a message "RFM not found on Channel" then check the SPI settings/wiring for that channel. If you see "DIO5 pin is misconfigured on Channel" then check the DIO5 setting/wiring. There is no current check for DIO0; any problems with that pin will result in packets not being received.
The gateway can uplink messages to the tracker. Currently this is restricted to time-based uplink slots using "UplinkTime" and "UplinkCycle".
The code uses Linux system time, so the gateway should ideally be using a GPS receiver the GPSD daemon. NTP may prove sufficient however.
For uplinks to work, both UplinkTime and UplinkCycle have to be set for the appropriate channel.
There are currently two types of uplink supported:
- Uplink of messages from the "SMSFolder" folder. For this to work, "SMSFolder" has to be defined and present. The gateway will then check for "*.sms" files in that folder.
- Uplink of SSD packet re-send requests. The gateway looks for an "uplink.txt" file in the gateway folder. The file is created by an external Python script (supplied) which interrogates the SSDV server.
It is possible for trackers to send out messages on a special "calling channel" as well as telemetry on their main frequency. The calling channel messages state the main frequency and LoRa modes.
This allows for gateways tp be normally left on the calling channel, so they then switch to each tracker as it comes within range.
There's nothing special about "calling mode" except that after a period (CallingTimeout seconds) of time without packets, the gateway returns to its default settings.
The display has a title bar at the top, scrolling log at the bottom, and 2 channel panels in the middle. Each panel shows something like:
Channel 0 869.8500MHz
Explicit, 250k, SF7, EC4:6
Telemetry 74 bytes
51.95028, -2.54443, 00138
Habitat SSDV 0000
0s since last packet
Telem Packets = 37
Image Packets = 0
Bad CRC = 0 Bad Type = 0
Packet SNR = 10, RSSI = -67
Freq. Error = 1.0kHz
Current RSSI = -64
The "Habitat" text appears during uploads to habitat. Normally it will flash up then disappear quickly; if it stays on (not flickering) then the upload is slow.
The "SSDV 0000" text shows the current state of the SSDV upload buffers. There are 4 upload threads and each can handle up to 16 (0-9-A-F) packets in its queue.
Normally, even with fast SSDV, uplinks should happen quickly enough for there to be no more than 1 or 2 active threads each with 1 packet being uploaded.
Interactive Features
====================
The following key presses are available. Where appropriate unshifted keys affect Channel 0 and shifted keys affect Channel 1.
Many thanks to David Brooke for coding this feature and the AFC.
Detect if DIO5 isn't correctly mapped (default level != high), warn and disables the channel.
Detect if the RFM isn't responding (reg 0x42 == 0x00), warn and disables the channel.
Warn if both receivers are disabled or unconfigured.
Removed message queue test code - functionality was behind that of the main code path, and would have required updating for the other changes in this set.
Added storage of at-time-of-receive-configuration in rx_metadata_t struct. This is copied into the queued telemetry_t structure when a Telemetry Packet is processed.
Added upload of receiver frequency (with detected offset) to Habitat with payload telemetry ( Issue #15 ). Mostly ported from Pull Req #28 which has been tested by @dbrooke .
Added logging of additional metadata parameters in packet.log (Issue #5 )
Removed duplicate 'LogTelemetryPacket()' call in habitat thread. (Already called in ProcessTelemetryMessage)
By me:
Added "Dataport" server socket for raw data (like port 7322 in dl-fldigi)
Added "<" sentence type, for telemetry that is not to be uploaded to Habitat.