Weekly Newsletter - May 4, 2025

Highlights

General

• Sard asked about a decent noise floor, initially questioning if -86 was acceptable and whether higher or lower numbers were better. Later, after installing an LNA, the noise floor was around -76, which prompted further inquiry and sharing of the LNA being used (Amazon link included). Mentioned pairing the setup with a specific antenna, sharing photos of the build. 🔗
  https://www.amazon.com/gp/aw/d/B09T39P1C1?psc=1&ref=ppx_pop_mob_b_asin_title
  https://www.amazon.com/gp/aw/d/B086YV2QLS?psc=1&ref=ppx_pop_mob_b_asin_title
  
  
  
• Jason inquired about the suitability of an LNA with a working range of 420-480MHz for use around 400MHz, where many satellites are positioned. 🔗
• Jason shared their setup built from random parts, a TTGO T-Beam, and a ‘dodgy antenna’, and included a picture of it. 🔗
  
• Stefan/OE6ISP advised that when using an LNA with a T-BEAM, the T-BEAM should be kept at least 2m away from the antenna or placed in a shielded metal case to avoid QRM emitted by the T-BEAM, which is a specific problem with T-BEAM boards. 🔗
• G4lile0 announced that autotune mode was activated on the Tianqis to generate a pseudo DDOS attack to test the performance of the new server. 🔗
• B is looking to convert their station to solar with a 5v solar panel and is asking for recommendations for a solar controller board to use with the battery. 🔗
• G4lile0 announced that the pseudo-DDoS attack experiment has concluded and the new server successfully handled the load. They also mentioned that the autotune feature for the Tianqi satellites has been disabled, and they will continue to be received as usual in surveillance mode. 🔗
• holysmoke_pdx mentioned @tinygs_personal_bot and used the /mqtt command. 🔗

Technical Problems

• Rogerio asked for help, as they haven’t been able to receive anything and shared photos of their setup. 🔗
  
  
  
• n3v1l reported that the station dashboard shows packets as being received the previous day, despite it being April 29th. 🔗
  
• Porky50 reported issues accessing the TinyGS dashboard after installation, as it persistently requests a username and password that are not being accepted. G4lile0 responded to Porky50 suggesting that the username is ‘admin’ and the password is the one assigned during setup, and provided a link to the FAQ. Notsure7 added that pressing the button for 8 seconds makes the recovery access point available again. 🔗
  https://github.com/G4lile0/tinyGS/wiki/FAQ

Antenna Building

• K5MPH1 shared a photo of an antenna cut for TinyGS. 🔗
  

Share your setup

• Brian shared photos of their setup. 🔗
  
  
  

Events

New Satellites

Learning Resources

Beta Firmware Testing

• Notsure7 reported initial issues with compiling the firmware, showing an older version number, then resolved it by merging the changes and confirmed it’s now working. 🔗
  
• B asked about trying the beta software, including whether it’s open to everyone, if a different antenna is needed, whether FSK satellites can be received with a 433MHz dipole, and if it’s possible to reinstall the stable firmware if issues arise. After receiving instructions, confirmed that beta was installed. Asked if modulation needed to be changed to FSK to pick up a station. 🔗
• G4lile0 shared a link related to beta firmware testing and mentioned that the modem configuration now includes a CRC check, making it impossible to descramble packets without the PN9 whitening decoder. 🔗
  https://t.me/c/1448773154/78484/166892
• Estbhan commented on FSK metrics with SX1268, noting that the SNR value is always -20 dB and the frequency error is always 0.0 Hz, and asked if 0 dB SNR is a constant value for Stefan/OE6ISP. 🔗
• Stefan/OE6ISP reported getting all CRC errors using FW 2504271 and asked if 2504272 is necessary. 🔗
• SV2HWM mentioned they have just installed the 2504272 FW to test reception from GeoScan satellites using an antenna with an LNA/BPF for 435 MHz and inquired how to limit reception to this band only. 🔗
• Notsure7 reported that their station became deaf with FW 2504271 and would like to know how to limit the frequency range, particularly for a BPF+LNA setup, same as SV2HWM scenario. 🔗
• G4lile0 mentioned that firmware versions 2504271 and 2504272 are identical except for the status number and that the CRC values are only handled in autotune mode. Trying to fix the reception manually will cause the CRC values to be missed. 🔗
• Stefan/OE6ISP is running in autotune mode and only allowing tuning for Colibri, which should work but needs further research. They also mentioned that ignoring tuning requests for unwanted satellites is possible, but this will not work to select a set of satellites, because you can only suppress requests, not add some, and clarified that doing it in the source code is easier, but the on/off trick will also work. 🔗
• Juan Pablo mentioned that the latest test version doubles the number of packets received. 🔗
  
• dg0nf reported having installed version 2504272 on 29.05.2025 but has seen only half the amount of packets since then with station DG0NF_433, using the same setup as previous days, asking if there is a newer version available as a bin file. 🔗
  
• G4lile0 shared insights about FSK reception, suggesting the use of Heltec WiFi LoRa 32 (V3 with ESP32-S3) Dev-Board with SX1262 and emphasizing the importance of adding an LNA. G4lile0 provided links to various stations: [https://app.tinygs.com/station/NFDiJee@6575912835\](https://app.tinygs.com/station/NFDiJee@6575912835), [https://app.tinygs.com/station/ZathTGS\_Heltec@1516011560\](https://app.tinygs.com/station/ZathTGS\_Heltec@1516011560), [https://app.tinygs.com/station/GSfbs01@6494555969\](https://app.tinygs.com/station/GSfbs01@6494555969), [https://app.tinygs.com/station/DG0OPK\_433\_2@5491882782\](https://app.tinygs.com/station/DG0OPK\_433\_2@5491882782), [https://app.tinygs.com/station/EA8DLJ\_256B@1419892453\](https://app.tinygs.com/station/EA8DLJ\_256B@1419892453). Also added that FKS it’s not easy, and seems that SX126x perform better, offering thanks for the feedback and stating plans to double-check for bugs on the SX127x, finally, disabled CRC checking on the modem config to see what we receive. 🔗
  https://app.tinygs.com/station/NFDiJee@6575912835
  https://app.tinygs.com/station/ZathTGS_Heltec@1516011560
  https://app.tinygs.com/station/GSfbs01@6494555969
  https://app.tinygs.com/station/DG0OPK_433_2@5491882782
  https://app.tinygs.com/station/EA8DLJ_256B@1419892453
  
  
• Stefan/OE6ISP asked what is unique to EA8DLJ_256B, because this appears to be the only station which can receive FSK without Crc errors. Later said that Colibri is not transmitting FSK but GFSK. Showed that the received CRC is always the same. Reported the reception of a signal 2k5 off frequency. Added that he will setup stations for a comparison with a sdr and satnogs decoder on the same antenna and compare the results. Mentioned that he could never decode a valid packet with CRC-check, even though they are all looking good, like in the log. Provided a picture. 🔗
  
  
  
• Estbhan explained that satellites transmit in GFSK, with bit shaping indicated by the ook parameter (ook=2) in the local dashboard satellite configuration chain. Also, clarified that the CRC calculation and de-whitening are performed by software, suggesting no performance difference between SX1278 and SX1268 in this regard and shared a link to [https://notblackmagic.com/bitsnpieces/ax.25/\](https://notblackmagic.com/bitsnpieces/ax.25/). Inquired about whether Stefan’s RF setup is on the roof or indoors, suggesting that temperature drift could cause KHz drift. Later, stated that we do not use that de-whitening piece of software. Is using BitCode class you will see a new PN9 method. Is that one. It is called when a packet is just received in raw, whatever chip is used. Shared an image. Finally, inquired whether Stefan/OE6ISP had received any good packet from Stratosat TK-1 and said that for some reason Stratosat packet length is shorter and that it is limited to 64 bytes (for that reason he migrated to the SX1268). 🔗
  https://notblackmagic.com/bitsnpieces/ax.25/
  
• Notsure7 discussed the usefulness of displaying battery percentage versus raw voltage readings from ADC inputs for monitoring battery levels. Notsure7 believes that showing a percentage is hard to compute and not very useful, suggesting instead a simple voltage reading, which has been done before. He suggests that TinyGS should report the most seen divider on current boards, and users can calculate the difference, percentage or SOC. He also suggested to use an ‘enable’ radio button followed by a ratio value. 🔗
• Stefan/OE6ISP performed tests on FSK (Colibri), initially experiencing no decodes for days. The issue was identified as a frequency mismatch, with Colibri being approximately 2.7 kHz higher than the station’s frequency according to Satnogs data. After correcting the RX frequency, decodes were successful again, particularly with a long Yagi antenna, although the signal remained weak on the omnidirectional antenna. The user also shared waterfall images from a GPSDO-stabilized IC-9700 showing the RX-signal from Colibri 2k7 higher than expected. 🔗
  
  
  
• G4lile0 updated the frequency of ‘Colibri-S’ to 436.8377 MHz but noted that the satellite appeared as ‘Unknown’ due to a kaitai parser failure, which expected a packet length of 74 bytes but received only 64 bytes. As a quick workaround, the Geoscan telemetry decoder for ‘Colibri-S’ was replaced with a plain ax25frame decoder. 🔗

Balloons

• dmytrokhmara plans to launch a weather balloon using a t-Beam lilygo 433Mhz as a telemetry transmitter and wants to use the tinyGS network for receiving data. They are asking for tutorials on how to add their balloon data to be parsed by tinyGS, generate a *.ksy file, and integrate it into the tinyGS server, also requested an example of how to use t-Beam lilygo as a balloon tracker, sharing their telemetry message format. 🔗

Announcements

• gmag11 used the /connect command for stations wEkl, G0oP and IX1C 🔗

Featured Conversations

• Community members are actively sharing their station setups and discussing antenna and LNA configurations to optimize signal reception and minimize noise, contributing to enhanced overall performance.
• There’s been significant progress in beta firmware testing, with users reporting increased packet reception rates and collaborative troubleshooting of CRC errors and FSK transmission issues.
• Frequency adjustments for Colibri-S have led to successful decodes after identifying and correcting a frequency mismatch, showcasing the importance of precise tuning for accurate satellite tracking.

What’s next

Join the TinyGS community to share your expertise, participate in beta testing, and contribute to collaborative problem-solving. Together, we can enhance the TinyGS network and expand our understanding of LoRa satellite tracking!