Close
0%
0%

Project Boondock Echo

Remote Radio Message Recording, Queueing, and Transmission (for Normal and Emergency Communications)

Similar projects worth following
Radio reception in mountainous terrain is sporadic. During an emergency, poor communication can cost lives. The proposed solution is internet-backed time-shift radio.

This project uses commercial off-the-shelf handheld radios and a microcontroller-based internet gateway to receive and store messages on a server where they can be queued for playback online or through a remote repeater. This solution allows increased communication in mountainous terrain with limited capital expenditure. Radio operators can capture traffic during a pileup, monitor multiple frequencies of interest, and replay important messages.

https://youtu.be/Q4VXa9YBc1A

This project can be extended to the entire amateur, commercial, and emergency radio space to provide improved reception and "answering-machine" type service. Future project development may allow speech-to-text and text-to-speech to quickly identify important messages and allow hearing-impaired individuals to enjoy their radios ag

Here's the scenario:

La Habra Heights and the surrounding area are in an area of local peaks and valleys.  We service three or four communities with a local "fire watch."   We have a commercial radio license, so we don't have to license each member individually, but many of us are practicing HAMS.

Issues:

1) During an emergency (fire or otherwise), we cannot reach all of our members with a single repeater.  No one location will work.  And since we are in an urban/wildland interface, we can only put repeaters in non-ideal locations.  

2) Also, during an emergency, all hell breaks loose as far as communications go.  It's not unusual for me to monitor 6-8 frequencies (2-3 repeater frequencies, fire from 3 agencies, police gen & tac, ham freqs), and when they all talk at once, which invariably happens, it's a stressful mess.)

Here's my proposed solution to both issues (but I'm open to other solutions, including SDR).  
1)  I get a group of 6 Baofengs and feed the audio into internet gateways that stream it to a server on the internet with time stamps.  We could even drop additional packages off at select places through the local area as "listening posts."  

The ones scattered throughout the city would be tuned to our repeater frequency.  
The ones in the communications tent would be tuned to police/fire/ham bands.
All audio gets tagged with freq & time stamp and sent to an internet server via an internet gateway.


2)  A computer & web interface in the com tent that can prioritize and playback the messages one after another, so nothing gets lost.

3)  Some radios that can transmit to all the repeaters at once.  The command tent would push a message to the internet, the gateways would see it and play it back over the repeaters when they were quiet.

But Boondock Echo's usefulness doesn't end there.  The Boondock Echo device can function as an answering machine for amateur radio operators who wander away from their radios, and cloud services allow the Boondock Echo device to perform noise cancellation, speech-to-text and text-to-speech conversion, and more!  Future development of the software can allow remote station operation through a smartphone.  

Standard Tesselated Geometry - 242.66 kB - 08/25/2022 at 22:16

Download

Standard Tesselated Geometry - 248.91 kB - 08/25/2022 at 22:16

Download

Standard Tesselated Geometry - 76.25 kB - 08/25/2022 at 22:16

Download

  • 1 × Handy-Talkie (https://www.amazon.com/dp/B08J48STLB or similar) ($25) Inexpensive https://www.amazon.com/dp/B074XPB313 or similar
  • 1 × ESP32 based Audio interface (https://www.amazon.com/dp/B0B5XKG5NK or other vendor) Audio interface to the Radio.
  • 1 × Audio cable 3.5mm to 3.5 mm RTS (https://www.amazon.com/dp/B017PT8XWU or similar) Audio cable for radio speaker out to Boondock Echo input
  • 1 × Audio cable 3.5mm to 2.5 mm RTS (https://www.amazon.com/dp/B01MDVLLDE or similar) Audio cable for audio level adjuster to Handy-Talkie microphone input.
  • 1 × Audio Level Adjuster 3.5 mm male to 3.5 mm male (https://www.amazon.com/dp/B08X6HY268 or similar) To reduce clipping

View all 9 components

  • Preparing for the Future of Boondock Echo

    Mark J Hughes2 days ago 0 comments

    KC is putting all of his energy into the Boondock Echo web interface.  We have all basic features incorporated at this time.  We can receive messages and push them to the server and pull messages from the server to transmit.  KC is working on the web interface to add advanced features such as noise cancellation, speech-to-text, and more.  

    Should we win the prize, we plan to create a custom PCB that plugs into a handi-talkie and derives power from the audio connectors.  However, there's no time to develop and iterate before final judging.  Additionally, custom hardware hurts us here since we can achieve all our current goals with commercial off-the-shelf components for well under $100.

    But since I'm not half the programmer KC is, there's not much for me to do in the source code modifications that wouldn't just slow KC down.  

    So I'm working on other roadmap features for the Boondock Echo.  Future feature tackled last night was Remote tuning

    Remote tuning

    Baogeng-UV5R

    Remote tuning of a Baofeng HT appears to be a non-trivial task.  I can quickly open the HT radio and interface the keypad with a microcontroller, but that might be difficult to make a long-term solution, and there's an excellent chance it will void any FCC certification the radio has.  There is no direct serial interface, but it might be possible to use a microcontroller as a device programmer through the speaker/microphone port.  Then find out where in device memory the current frequency is stored and change it.  Not terrifically difficult, but even if it is technically possible, it might require power cycling the HT, and it would take a little while to decode the memory bit map.  

    Anytone-778UVII

    The Anytone-778UVII is an inexpensive ($129) 25 W mobile radio with an RJ-45 jack on the front that accepts a remote handset.  The handset has 17 push buttons, a PTT switch, an up switch, a down switch, and a button lock.  And since it's an RJ-45 plug/jack, it's trivial to listen in on communications between the handset and radio (tap pos 1 and 8).  Once I probed and found the data pin and set the RS232 specs (9600, 8N), decoding took 10 minutes.  Here's what the radio sends when you push the PTT

    This is the most complicated data packet the handset has in it.  53 and 54 are the ASCII codes for "ST" or "Start Transmission".  04 is "EOT" or "End of Transmission", 07 is "BELL", etc.  In short, they made this thing very, very easy to understand.  I'll play with this a bit more when an antenna dummy load arrives.  Right now, the radio detects the high SWR and shuts off immediately.  I expect the radio keeps churning out 00 bytes to indicate continued transmission as long as the PTT button is pressed.

    Each key is similarly easy to understand.  A 7-byte data packet contains the packet header, data, and then Line Feed and Carriage Return

    The key information is encoded in the 5th byte.  And again, it couldn't be easier to understand.  The programmers used the ASCII codes for each key 0-9, "/" for "A/B" button, "*" and "#" are the relevant ASCII codes for those characters, and "PA", "PB", "PC," and "PD" are just ASCII codes for "A", "B", "C", and "D" respectively.  

    ButtonData stream from Handset
    A/B 41 4C 7E 4B 2F 0D 0A
    0 41 4C 7E 4B 30 0D 0A
    1 41 4C 7E 4B 31 0D 0A
    2 41 4C 7E 4B 32 0D 0A
    3 41 4C 7E 4B 33 0D 0A
    4 41 4C 7E 4B 34 0D 0A
    5 41 4C 7E 4B 35 0D 0A
    6 41 4C 7E 4B 36 0D 0A
    7 41 4C 7E 4B 37 0D 0A
    8 41 4C 7E 4B 38 0D 0A
    9 41 4C 7E 4B 39 0D 0A
    * 42 4C 7E 4B 2A 0D 0A
    # 43 4C 7E 4B 23 0D 0A
    PA 44 4C 7E 4B 41 0D 0A
    PB 45 4C 7E 4B 42 0D 0A
    PC 46 4C 7E 4B 43 0D 0A
    PD 47 4C 7E 4B 44 0D 0A

    So, to send a command to set the frequency...

    Read more »

  • Boondock Echo Assembly Video

    Kaushlesh Chandel7 days ago 1 comment

    Posting a video on Boondock Assembly. This is Part 1 of the three-part video explaining setting up your boondock echo, programming it, and setting up the web server.

    !!! Latest STL files are available on GitHub.

    Github link to STL Files

    Links to buy items on Amazon

    Li-ion Battery

    Push button for on/off

    3W 4Ohm Speaker

    ESP32 Audiokit by AIThinker

    Audio cable for Radio

  • Software Development Continues

    Mark J Hughes09/04/2022 at 18:15 0 comments

    KC continues to work on the project behind the scenes.  Today he captured audio at 48k!  Crazy high bit-rate.

    As always -- you can monitor his progress on the github here:  https://github.com/kaushleshchandel/boondock

  • New Boondock Echo Case

    Mark J Hughes08/25/2022 at 22:15 0 comments

    KC improved the case design so the screws come in from the bottom.  Nice job KC!.  See latest files under the main project files location.

  • Case, Battery, and User Interface Update

    Mark J Hughes08/19/2022 at 18:53 0 comments

    KC is hard at work on Boondock Echo.  The board works and is on the internet.  He can send data to and from the device to his computer.  He also had the idea to add a speaker as part of the user interface.  Displays need to be looked at.  A speaker can play audio to anywhere in a room.  So saying things like "internet offline" or "message waiting" over a speaker will likely prove more useful for this project.

    Time for a case!

    The microcontroller will need a battery backup to be useful in emergencies.  So KC created one.

    KC does good work.  Now back to programming!

  • Parts in Hand -- First Success

    Mark J Hughes08/17/2022 at 18:25 0 comments

    KC has parts in hand and quickly got audio sent to the microcontroller and pushed out through the radio.

    The radio uses VOX (voice-activated transmission), which will allow reverse-repeater functionality.  A net controller can push a message through all listening posts or select listening posts.

    One issue is that the audio streamed through the device is choppy.  It must be uploaded to the device first, then played back and transmitted.  We haven't investigated whether it's a bandwidth issue or a microcontroller limitation.  For now, it doesn't matter.  The next step is getting audio from the radio to the server.  Then it's all backend programming.

    For anyone wondering, KC is the coding genius here, I'm a ham-fisted monkey who crashes the stack into the heap like a noob.  I'm mostly his hype man at this point :)
    -- Mark

  • Back and Forth Project Scope Discussion

    Mark J Hughes08/12/2022 at 22:31 0 comments

    KC and I had several back and forth messages through email to determine the scope of the project.  (Lots of detail, but you can see the general thought processes below):

    KC -- check this out:

    https://github.com/sharkrf/srf-ip-conn-srv

    And Openspot 4 by SharkRF:  https://www.sharkrf.com/products/openspot4/learn-more/

    On Tue, Jul 19, 2022 at 5:26 AM Kaushlesh Chandel wrote:

    Hi, I agree. I am not thinking of starting Mobile first. First, ill work on a raspberry pi and server-side code. I agree with API architecture. The server-side code should be API driven. So, a Pi, microcontroller, PC, Mobile, they call can talk to it alike.  About the headphone jack, most flagship phones are removing that. Though there are lower-end phones still with the jack. We have two options: a Bluetooth-based device or a headphone adaptor for iPhone & Android phones.  Thanks! KC On Mon, Jul 18, 2022 at 9:39 PM Mark Hughes  wrote:

    KC -- it occurs to me that much of the initial testing (and getting people excited about the project) might be accomplished with a radio and your regular work computer. Once we demonstrate specific functionality (and we could do that with a $100 refurbished laptop) then we can tackle the harder job of developing an app.  In fact, you could develop the API and let others do the hard work for you. I also thought of a possible complication.  I upgraded phones a few months back and I no longer have an earphone jack.  Are they phasing out industry wide?  I know Apple and Samsung are leaders -- but I have absolutely no idea about what's happening in the other markets. These are all just thoughts -- you of course have the latitude to move in the direction you are most passionate about. On Mon, Jul 18, 2022 at 1:30 PM Mark Hugheswrote:

    Ooh -- the discord idea is genius (if we can get it to work). I've not used winlink but I can look into it.  Most amateur radio data happens at very, very slow speeds.  Think dial-up modem or worse. And I will look for apps!   Thanks KC! On Mon, Jul 18, 2022 at 1:23 PM Kaushlesh Chandel  wrote:

    Cool! even if we do buy RPi's (or any Arm7-based SBC) the BOM will end up being much higher than just using a good old phone. The phone-based app lets anyone use their existing phone. And we can beacon these phones using APRS style packets. I have some more features in my mind. We can chat over the weekend. We might find a way to link the radio communication to discord or something similar. Thus we don't have to build expensive server-side infrastructure. Though working stand-alone is a must-have requirement. If the mobile phone's hardware can do reliable Audio to text conversion, then it can link up to so many chat-based services. Question... Have you used win-link? Can Winlink send/ receive compressed audio files? Meanwhile, please research the apps out there; that do similar stuff. I'll look as well. I'll talk to some folks specializing in mobile app development. I have built Android & iOS apps, but I am basic.  Thanks, KC On Mon, Jul 18, 2022 at 3:10 PM Mark Hughes wrote:

    I like it!  As I mentioned in the call, I'm not married to the RPi idea -- especially with low availability.  That was just one thought of a possible way to solve the problem.  The phone sounds like a better solution! And who knows -- in a few years, maybe we'll have all sorts of integrations / customization options -- RPi, ESP, laptops, etc... So if you think the phone is the best path forward, I'm all in.  Let's go phone! One thing I would like to advise you though -- the cellular signal up here is absolute crap -- very hit and miss.  So definitely want to make use of the onboard wifi for data transfer where possible.   They even apparently make OTS cable assemblies just for this purpose :) https://www.amazon.com/BTECH-APRS-K1-Interface-APRSDroid-Compatible/dp/B01LMIBAZW/ref=asc_df_B01LMIBAZW...

    Read more »

  • Initial Communication

    Mark J Hughes08/12/2022 at 22:30 0 comments

    Hello Kaushlesh,     Thanks for replying back so quickly!  You mentioned you were looking for a project -- I have one that is 95% software based (using COTS equipment).

    I am net controller for the La Habra Heights Fire Watch.  We're in a very dry, very hilly area and I have a need, and an idea of how to accomplish it.  But don't have the time or requisite programming experience to make it happen.  I'm not insistent on the solution -- this is just a proposal.

    Here's the scenario:
         La Habra Heights and the surrounding area are in an area of local peaks and valleys.  We actually service three or four communities with a local "fire watch" -- think CERT.  We have a commercial radio license so we don't have to individually license each member, but many of us are practicing hams.

    Issues:
    1) During an emergency (fire or otherwise), we cannot reach all of our members with a single repeater.  There is no one location that will work.  And since we are in an urban/wildland interface, we can only put repeaters in non-ideal locations.  

    2) Also during an emergency, all hell breaks loose as far as communications go.  It's not unusual for me to have to monitor 6-8 frequencies (2-3 repeater frequencies, fire from 3 agencies, police gen & tac, ham freqs) and when they all talk at once, which invariably happens, it's a stressful mess.)

    Here's my proposed solution to both issues (but I'm open to other solutions, including SDR).  
    1)  I get a group of 6 Baofengs and feed the audio into RPi picos that stream it to a server on the internet with time stamps.  We could even drop additional packages off at random places through the local area as "listening posts".  
    The ones scattered throughout the city would be tuned to our repeater frequency.  
    The ones in the communications tent would be tuned to police/fire/ham bands.
    All audio gets tagged with freq & time stamp and sent to a internet server via RPis (or similar)
    2)  A computer & web interface in the com tent that can prioritize and playback the messages one after another, so nothing gets lost.
    3)  Separate Pis & Radios that can transmit to all the repeaters at once.  The command tent would push a message to the internet, the pis would see it, and play it back over the repeaters when they were quiet.

    There of course might already be a solution out there, I don't know.  I've been trying to research and investigate, but my time is limited.  Any advice or direction you could offer would be appreciated.  And if it's something you'd be interested in, and want it for a personal project, by all means, claim it. 

    Thanks,
    Mark

View all 8 project logs

Enjoy this project?

Share

Discussions

Mark J Hughes wrote 08/19/2022 at 19:27 point

If anyone has additional ideas or would like to help KC program, please reach out!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates