You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This radio is 1/3 the price of the other one, and it has the benefit of being future-proof in that NWS can add various modulations to the signal and we "just" have to add software to deal with demodulating the signal. Of course, this means there's a continuous signal processing task, but it also means the signal is already digital, making it easier to play the audio from the tornado warning directly.
eBay has a number of things like this that might be the same chip for about half the price of Adafriut's, but I would be cautious of designing such a device into a deployed product without buying a bunch because we don't want the specs to change.
The component must, at a minimum, generate a new_message event, with a SAME message as payload, exactly the way the RadioComponent does today. It could also produce an audio recording of the message, allow mute/unmute of the audio from the radio, and so forth. The audio from the radio must not conflict with the audio from message playback.
The best implementation of this will involve reusing SAME message processing which is also used in Si4707, and will require starting and ending messages at the same point in the SAME transmission - omitting ZCZCZC- and anything after the final -.
The text was updated successfully, but these errors were encountered:
http://www.rtl-sdr.com/new-eas-same-weather-alert-decoder/
This radio is 1/3 the price of the other one, and it has the benefit of being future-proof in that NWS can add various modulations to the signal and we "just" have to add software to deal with demodulating the signal. Of course, this means there's a continuous signal processing task, but it also means the signal is already digital, making it easier to play the audio from the tornado warning directly.
eBay has a number of things like this that might be the same chip for about half the price of Adafriut's, but I would be cautious of designing such a device into a deployed product without buying a bunch because we don't want the specs to change.
The component must, at a minimum, generate a new_message event, with a SAME message as payload, exactly the way the RadioComponent does today. It could also produce an audio recording of the message, allow mute/unmute of the audio from the radio, and so forth. The audio from the radio must not conflict with the audio from message playback.
The best implementation of this will involve reusing SAME message processing which is also used in Si4707, and will require starting and ending messages at the same point in the SAME transmission - omitting ZCZCZC- and anything after the final -.
The text was updated successfully, but these errors were encountered: