Open darksidelemm opened 1 month ago
dalewegner
commented
1 month ago Made this modification to server.js and it now correctly posts to aprsis. var APRS_PAD_ALT = null; APRS_PAD_ALT = ((APRS_ALT<100)?"0000": (APRS_ALT<1000)?"000": (APRS_ALT<10000)?"00": (APRS_ALT<100000)?"0": "") + APRS_ALT; APRS_comment_to_send = "/A=" + APRS_PAD_ALT +" "+ APRS_Comment; //APRS_comment_to_send = "/A=" + APRS_ALT +" "+ APRS_Comment
wb9coy
commented
1 month ago Hi Dale/Mark, I have developed a whole new system that runs slightly faster but uses Reed Solomon par 16 coding. The new system also uses the RTL-SDR to receive FSK pictures and telemetry. It flew without issues on the last student flight so it is almost ready to post to git. I also upgraded to the latest version of nodeJS.
Mark, I have been looking at the temperature calibration data and it is not clear to me how to use it. I did come up with my own calibration data but it does not seem to work for temps below -30F. Also, the loop oscillator needs almost 5 seconds to stabilize. That does not make sense. Maybe we could have a Zoom meeting to discuss my findings regarding the stock temp sensor.
My latest development is to use an RPI with a RFM95 chip to generate FSK for pictures and HORUSV2 for telemetry. No Sonde. There is chatter about HORUSV2 becoming the new APRS PHY layer. 4FSK Horus is far superior for tracking !!!!!
From: dalewegner @.> Sent: Wednesday, July 31, 2024 5:02 AM To: wb9coy/HAB_WebServer @.> Cc: Subscribed @.***> Subject: Re: [wb9coy/HAB_WebServer] APRS packet has incorrectly formatted Altitude data (Issue #1)
Made this modification to server.js and it now correctly posts to aprsis. var APRS_PAD_ALT = null; APRS_PAD_ALT = ((APRS_ALT<100)?"0000": (APRS_ALT<1000)?"000": (APRS_ALT<10000)?"00": (APRS_ALT<100000)?"0": "") + APRS_ALT; APRS_comment_to_send = "/A=" + APRS_PAD_ALT +" "+ APRS_Comment; //APRS_comment_to_send = "/A=" + APRS_ALT +" "+ APRS_Comment
— Reply to this email directly, view it on GitHubhttps://github.com/wb9coy/HAB_WebServer/issues/1#issuecomment-2260358408, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABOSFFRQFCTUBHNWOYCQWS3ZPDG47AVCNFSM6AAAAABLVLADDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQGM2TQNBQHA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
darksidelemm
commented
1 month ago On the RS41 sensor stalk - I've given up on them. They are too fragile, are often damaged on recovery, and on any launch would likely be single-use only. We don't need meteorological quality data, adding on something like a BME280 gives us enough 'extra' information to make pretty plots for students to look at. If we want 'real' data we just look at the data from the most recent met bureau launch!
As for imagery from a RPi - we've been doing that for years and years! See: https://github.com/projecthorus/wenet We run at 115kbit/s though, and use LDPC coding. Works very nicely, high quality images, they come down fast, and we get spatial diversity with images being recombined and visible on https://ssdv.habhub.org/ RX with RTLSDR. The wenet modem can also transfer 'arbitrary' data, and as of the most recent versions it will send positional information which gets uploaded and displayed on sondehub.
Horus-V2 as PHY for APRS.... not without big changes. APRS packets are very long and inefficient, stuffing them into Horus-V2 would result in very long transmissions! I have looked into allowing the horus-v2 modem to decode longer frame sizes, e.g. 64, 128 bytes, but haven't had time to do much about it. This would at least allow for arbitrary callsigns, rather than the lookup-table approach used now. As an APRS alternative I'd suggest something more like https://cats.radio/, though you'd want to run it at a lower baud rate to get more robustness.
dalewegner
commented
1 month ago We have hundreds of these RS41s to repurpose, which allows us to fly high risk flights over water. With a lost rate of 50% this RS41 camera system is very attractive. When we want high quality pictures we put in a Gopro 4 or 5 and a Spot. For the kids the immediate stream of photos is a wow factor, so they can feel what the payload is experiencing. When we get the Gopro cameras back the students are just so so about seeing the pictures. They seem to like the adrenaline of the stream more during the 2-3 hour downtime part of the flight. Kids living for the moment. With that said, on select safe land flights we want to try the Wenet next.
Thanks guys for providing these photo options.
On Wed, Jul 31, 2024 at 11:35 AM Mark Jessop @.***> wrote:
On the RS41 sensor stalk - I've given up on them. They are too fragile, are often damaged on recovery, and on any launch would likely be single-use only. We don't need meteorological quality data, adding on something like a BME280 gives us enough 'extra' information to make pretty plots for students to look at. If we want 'real' data we just look at the data from the most recent met bureau launch!
As for imagery from a RPi - we've been doing that for years and years! See: https://github.com/projecthorus/wenet We run at 115kbit/s though, and use LDPC coding. Works very nicely, high quality images, they come down fast, and we get spatial diversity with images being recombined and visible on https://ssdv.habhub.org/ RX with RTLSDR. The wenet modem can also transfer 'arbitrary' data, and as of the most recent versions it will send positional information which gets uploaded and displayed on sondehub.
Horus-V2 as PHY for APRS.... not without big changes. APRS packets are very long and inefficient, stuffing them into Horus-V2 would result in very long transmissions! I have looked into allowing the horus-v2 modem to decode longer frame sizes, e.g. 64, 128 bytes, but haven't had time to do much about it. This would at least allow for arbitrary callsigns, rather than the lookup-table approach used now. As an APRS alternative I'd suggest something more like https://cats.radio/, though you'd want to run it at a lower baud rate to get more robustness.
— Reply to this email directly, view it on GitHub https://github.com/wb9coy/HAB_WebServer/issues/1#issuecomment-2260809680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETWTEVCHMEZWFIQKKR64L3ZPD74ZAVCNFSM6AAAAABLVLADDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQHAYDSNRYGA . You are receiving this because you commented.Message ID: @.***>
The code within server.js that is submitting position reports to APRS-IS is producing packets of this form:
The altitude field (
A=93121) is incorrectly formatted. Altitudes should have 6 digits, and be zero padded if necessary, e.g.A=093121. This is why none of the APRS packets from this system are showing up with altitude correctly on APRS-IS, and it's also why they have not shown up on SondeHub-Amateur via our APRS-IS gateway.