Project Boondock Echo

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

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

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.

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!

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

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 Great work KC! On Mon, Jul 18, 2022 at 12:52 PM Kaushlesh Chandel  wrote:

Hi Mark, I spent the weekend thinking about the solution. I like your raspberry pi idea, but I feel that it would be easiest to build a mobile app that connects to baofeng radio via a cable. A phone has audio in/ audio out, wifi, Cellular, Bluetooth, processing, storage, GPS, Battery and pretty decent power management, and a display to configure the device Using a raspberry pi based solution will require.

• Input buttons etc.
• Some basic display
• Intelligent power management
• Li-ion battery
• USB soundcard with both audio in/out
• Cables for connectivity with baofengs.
• Wifi Enclosure
• So much more...

If an android app is built with a custom cable that connects baofeng to the Phone audio jack, we can make it work. A cheap android phone may cost like $150. And we can benefit from its cellular network. I will send you details on the application features and design. if you like, we can talk around the same time this week. Thanks, Kaushlesh (312-363-7664) On Fri, Jul 15, 2022 at 12:01 PM Kaushlesh Chandel wrote:

I am just finishing up... 5 min max. On Fri, Jul 15, 2022 at 11:18 AM markjarrodhughes wrote:

I am, thanks! Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Kaushlesh Chandel Date: 7/15/22 9:06 AM (GMT-08:00) To: Mark Hughes  Subject: Re: From Hackchat Hi Mark,  I hope you are still down for the meeting. I have one call just before my call with you. Please hang on if I get a few minutes late. Thanks, Kaushlesh On Thu, Jul 14, 2022 at 11:42 AM Kaushlesh Chandel < wrote:

On Wed, Jul 13, 2022 at 7:18 PM Kaushlesh Chandel  wrote:

Awesome then Friday it is. I’ll send a zoom link  KC On Wed, Jul 13, 2022 at 5:33 PM Mark Hughes  wrote:

Certainly -- I have a webinar runthrough tomorrow -- so perhaps Friday would be better if that works for you.  Also -- I think you have the timezone conversions reversed.  12 pm central should be 10 am pacific.  I'm available at either.Perhaps we could get a grant from the people on hackchat to pay for it all? On Wed, Jul 13, 2022 at 2:40 PM Kaushlesh Chandel wrote:

Hi, You seem to be in California time and I am in central time.  What morning time will work for you. Is 10 AM central time / 12:00 PM your time okay for you? I can send an invite. Thanks, Kaushlesh On Wed, Jul 13, 2022 at 4:00 PM Mark Hughes  wrote:

Hi Kaushlesh,    We could also go with RPi zero wireless, or an RPi 3 or RPi 4 -- I haven't done a feasibility analysis at all. We'd have multiple baofengs.  One for each listening location/frequency.  If we had 20 frequencies of interest, we'd buy 20 baofengs.  That's still only $400.  Scanning would cause the loss of information. It will queue the messages.  I don't know that I fully appreciate the two-generals problem.  But since each radio would have a RPi with it, it could get the time via NTP, correct?  And then we could append a radio-ID to each message too, so even if they have identical time stamps, they'd have different radio-ids, and would still be unique. Regarding the internet.  yes -- I thought of that too.  An external server might become unreliable in an emergency.  It should be possible to create an ad-hoc network that the pis can connect to.  Or in the case of a Pi3 or Pi4, just plug in a cable.  In that  case, you'd need a local server that can accept the information. As far as transmitting -- we wouldn't transmit through SDR.  We'd transmit through a high-power radio (5-50W) -- that's not a problem, we'd just have to key it. What is your availability?j Thanks, Mark KE6WOB On Wed, Jul 13, 2022 at 1:47 PM Kaushlesh Chandel wrote:

Thanks Mark, it's very interesting. And I totally understand the problem. And you also got to deal with Comm Tech ( Joke on Elk river fire incident, where Ham was fined 34K) I do get what you are trying to do. Please allow me to digest this information. Few things I can immediately think of... * Rpi Pico might not be powerful enough. Ill do more research. Recently Raspberry foundation released RPi Pico W, with Wifi module. but there are several options. *  Will you have multiple Baofengs tuned to different frequencies, or does it need some type of auto scan with squelch? * So it will queue the messages;causing an acknowledgment problem ( Two generals paradox) * Needing internet? Can Rpi's do digital mode on quieter frequencies? Maybe some kind of mesh. * Ive done work with SDR's like RTLSDR, hackrf one. they are good to receive radio but very bad at transmitting. Think like a few milliwatts Tx power. Nevertheless, it's a very interesting problem to solve. We should get on a Zoom call. I'd like to understand more about the problem and your proposed solution. What I understand so far, is a way to do some kind of multiplexing, so multiple communications can happen in case of an emergency. Thanks, Kaushlesh On Wed, Jul 13, 2022 at 3:14 PM Mark Hugheswrote:

Hello Haushlesh,     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. 

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