S-250 Shelter Build - Camper conversion and simplified comms-shack

[tim292stro]

What SDR gear to you plan on using?...

For HAM RX/TX, there are licensing requirements I have to abide by, so I'll be using the FlexRadio SDR line for simplicity - this is a half-depth 2U transceiver that can be remoted over TCP/IP networks (simple plug in for Asterisk). For the other bands, and for general listening and snooping, there are many COTS options available - the now famous RTL2832 SDR receivers, HackRF, BladeRF, etc... The problem is that most of these solutions are typically limited to one RX antenna, and I want to do broadband radio direction finding and filtering, in addition to non-transmission RADAR using RF energy in the free space (from other transmitters). This means I need high speed time-aligned RF inputs - like a 4-channel RF Oscilloscope that I can post-process on. What I want to be able to do is capture all the RFs



and be able to decode any signal of interest on the fly to know what is broadcasting in the receivable RF space, which direction it's coming from, and listen to and decode the signals which are legal to listen to. I'm attempting to design my receiver to cover two sets of broadband antennas that cover 5kHz-30MHz and 30MHz-6GHz, four antennas in each set (8 total).

...I've been following your posts on your various project and especially like the idea of connecting the radios into the VoIP system. Have you actually done this yet? How well does it work in practice? I mostly wonder about the TX/RX switching issues on the radio side of the equation.

I have had success - with short experiments, I've connected two Uniden PRO520XL's (no internal modifications) to RoIP102's and then to RaspberryPi's. I placed one at my parent's and one and my apartment and was able to broadcast across town both ways, change channels on the radios, and use a handheld CB to broadcast into the PBX. The hardest part was modifying the Asterisk conference bridge to support single party talking and the un-mute interlocking - the radio's VoIP bridge (raspberry Pi A+) calls into the PBX as a conference leader which gives it special audio privileges, everyone else dials in as a user. I'll probably submit that code into Asterisk later so it becomes part of Asterisk's permanent capabilities.

Basically the Raspberry Pi A+ board is running Raspbian (Debian Linux for Raspberry Pi), and a lightly modified LinPhone client. Raspberry Pi has Ethernet, audio, and GPIOs that can be programmed, so if you unplug the microphone from the radio and build an adapter that converts the speaker out and microphone in and key-switch to line audio (to the radio's mic) and mic audio (from the radio's speaker) and a GPIO, you can do two radios per Raspberry Pi (1/5th the cost of RoIP102, double the capability). To control channels on the CB radios, I use photodiodes to literally read the dual 7-segment displays, and a motor on a gear box to turn the knob. Remember FCC regs require that you not modify the radio for it to be legal in the CB band - and I was in direct control of both radios at all times which is required for a radio relay.

 

[serial14]

Sounds like you've got a custom solution brewing for your wide band RX solution. I agree that the single antenna/single RX limitation on the commercial offerings is sometimes annoying and limiting. We just got a multiplexer at work so that we can tie multiple RX SDRs into a single antenna system. Still need to try it out though.

I'm slightly confused on your VoIP setup. I'll first say that I'm familiar with everything you mentioned except the RoIP102's, though I understand their purpose. I've been running Asterisk for about 10 years now but have only recently become interested in expanding my solution.

I thought based on previous posts you were going to use the RoIP102's as the SIP gateway piece between the radios and asterisk. Based on your post though, its seemingly like you are now using a RPi running LinPhone as that bridge? What were you reasons for trying one way over the other? How are you managing PTT or VOX with the linphone solution? I have in the past used "baresip" on embedded processors for simple VoIP links so I wonder if it would potentially fit the bill here? Again though... I'm not sure about the PTT issue on the radio side. I guess thats really my mental trip up... controlling the PTT of a half duplex radio link.

 

[tim292stro]

BareSIP would be nearly equivalent to what I'm doing with LinPhone, the "lightly modified" part is that once the Raspberry Pi is hooked up to network and power, it tries to dial in as "master/host" for the conference bridge. I went this way because the RoIP was limited to VOX operation, and it occurred to me that I wasn't getting much out of the ROIP102 with the other modifications I felt were necessary, and the moment I wanted a feature or control the ROIP 102 didn't have there was no way forward. Meaning, I don't key up unless the interlocking logic on the conference bridge states that one talker is unmuted and active audio was not being received by the Raspberry Pi from the radio (think Nextel), so being that I had that logic to do this already in Asterisk I just needed to pass a keyup tone (DTMF "A") to the Raspberry Pi to close a relay and a keydown tone (DTMF "B") to open the relay. Since the DTMF tones for this extension are set for not passing DTMF in the audio channel (which we can do with VoIP), the softphone gets them in a side channel. I have a script on the Raspberry Pi that listens to the side channel on LinPhone for commands via DTMF to open/close the mic key, and to handle channel transitions ("C" for up, "D" for down, "*" for decimal, and "#" as a command separator). The Raspberry Pi echo's the DTMF commands back, so I get confirmation that the command was executed. I could not get channel control with the ROIP102 and that was a desire from the start.

In this way I have tighter control of the Radio-over-IP bridge. And did I mention it's 1/5th the cost of a ROIP102?

One other "toy" I've been playing with to attempt RoIP bridging is an XMOS multi-channel USB Audio board. With the appropriate ADCs/DACs I can do 16 radios with a single USB break-out board, and do I2C expansion to copy the IO control on the Raspberry Pi I've done. That way an Asterisk host would be able to directly access and control the radios via local audio ports and serial control, rather than adding latency through another bridge device and eating up network ports.

This same board is what I've been using as the basis for my CarPuter car stereo projects, the USB board outputs/inputs I2S audio (audio equivalent of I2C data). I purchased components (processor, amps) for and have been building Class-D amplifiers with I2S direct audio input via USB. Also have I2S AM/FM tuners (one active audio, one scanning, with SW fast-switching) so I can turn any USB capable Linux machine into a full car stereo.

 

[serial14]

Thanks for the explanation. That makes a lot of sense. As you mention, the RPi solution gives you a lot of future flexibility and customization paths.

So you mentioned here again you use DTMF codes to manually key and unkey the radio. That makes sense from a side channel perspective. From an operational perspective though. Does a user( human ) on a VoIP phone have to manually command the Key and Unkey events. Or do you have it tied in somehow to the audio conference system to dynamically do some sort of VOX at that level?

So the use case I'm thinking about for all this slick VoIP + Radio integration is the following. I've already got my radios, coax, antennas, etc centralized and rack mounted. I've also got asterisk setup with several VoIP phones around the house. So it would be slick to just pick up the phone, dial the radio extension, and then be able to call out to one of my friends over the ham radio link. But how would my ham radio friend, come in through the RF link and then "ring" a VoIP phone to get my attention? I kind of a mini auto patch type system? Have you tried something like that? It almost seems that your more focused on a radio net would operate "classically" and then outside people could dial in to join the party.

Many years ago I played with the "URI" product by DMK Engineering and the "AllStarLink" asterisk distro that some ham radio guys are playing with. The URI was a pretty cool product and certainly had potential. I had pretty good success with it linking into my existing asterisk system and doing classic phone patches and simple DTMF query commands. However, at the time I didn't have a true need or the "critical mass" of ham radio friends to make it worth while. I guess this approach of having the radios attached directly to the asterisk box is more what your second idea is like. Until now, I honestly had forgotten about that experiment I did.

Funny you mentioning carputers and RPi's. This weekend I've been putting a new distro on my RPi to make a it a better "car server" for the projects I'm currently working on. Its(RPi) certainly not the fastest kid on the block, but its sure easy and cheap and easy to get stuff done on. Sometimes I wonder.. who uses the RPi more? Kids learning about technology. Or engineers hacking them into projects.

 

[tim292stro]

...Does a user( human ) on a VoIP phone have to manually command the Key and unkey events, or do you have it tied in somehow to the audio conference system to dynamically do some sort of VOX at that level?...

Yes, and I did that for a few reasons. Firstly, I want people who would be using a traditional radio over VoIP to realize they need to take turns and not just start talking (it is half duplex after all). With the RoIP Conference Bridge the radio's RX audio traffic gets the highest priority with audio detection (similar to VOX). A user cannot key up the radio if the radio is receiving audio above the squelch gate, pushing the key button will give you a sqwak to alert you the channel is not idle. What I am working on is a feature built into the recording feature that stops the recording with a certain amount of silence - this would remove the need for the local transmitting party to manually key-off the radio, just press talk request and you get a "beep" when the mic is hot, then when you stop talking for a second or two it keys itself off. That's not ready yet and will probably coincide with pulling the radios into the Asterisk server itself as my project time permits. I have done the work to pull in several RFCs for PTT SIP in the conference bridge so it you have a phone that does PTT signalling on the SIP channel, pushing the PTT button would key-up, releasing it would key-off.

I am working on driving a LS-671/VRC with a H-250 for the local operator's station, which does have PTT capabilities.

...So it would be slick to just pick up the phone, dial the radio extension, and then be able to call out to one of my friends over the ham radio link...

That's how I have it set up, the radio is always in the conference bridge wen it's available, so you "call" the radio you want to talk to and you get the live audio for that radio through your handset or speaker phone. When you want to talk, you push the soft-key for it to key-up, then talk, and press the soft key to key-off.

I explained this in the FOBIC thread a bit, there are pretty pictures which should make it more clear .

...But how would my ham radio friend, come in through the RF link and then "ring" a VoIP phone to get my attention?...

Well here's the crux - for the sake of FCC regulations I consider Asterisk a phone system, that' how they've advertised it (even though now it is more of a unified communications system). Connecting a radio to a phone has certain regulatory requirements specifically the bridge has to be monitored by a human operator unless the operator is actively in control of all points of the system. With that in mind I didn't even bother to work on how to get the radio to place a phone call without some direct controlling action - VOX is not access control. The only action in the dialplan for the RoIP bridge is to dial into the conference bridge. It cannot do anything else without a human operator being on the bridge too.

...Its(RPi) certainly not the fastest kid on the block, but its sure easy and cheap and easy to get stuff done on...

Plenty awesome for a file server, web server, browser, media end-point, etc...

 

[Another Ahab]

Well here's the crux - for the sake of FCC regulations I consider Asterisk a phone system, that' how they've advertised it (even though now it is more of a unified communications system). Connecting a radio to a phone has certain regulatory requirements specifically the bridge has to be monitored by a human operator unless the operator is actively in control of all points of the system. With that in mind I didn't even bother to work on how to get the radio to place a phone call without some direct controlling action - VOX is not access control. The only action in the dialplan for the RoIP bridge is to dial into the conference bridge. It cannot do anything else without a human operator being on the bridge too.

Other than the old bureaucratic "rules are rules" reasoning, is there a sensible reason for the monitoring?

 

[tim292stro]

You know I'm a nut for security, VOX on a PBX system is not security, it's convenience (anyone who can speak would be able to transmit). Letting any caller (licensed or not) into a radio bridge is kind of like putting your gun on a conference table and letting anyone pick it up as use it as they see fit. I prefer to keep positive control of it - even from a design principal standpoint. One other consideration you have to worry about with VOX is noisy TX environments. If a sound nearby you was enough to trip VOX, you'd have an open mic while you don't want it.

Here's the basic logical rule for Local TX Assert:

IF --> "No RX Audio" AND "TX Not Asserted" --> THEN TX-ON

The logical rule for Local TX Deassert:

IF --> TX(USER) OR HOST --> THEN TX-OFF

To the previous poster's question, should a radio be on a bridge that no one has joined, a VOX setup can be used to detect radio RX audio and do a "tone page" or ring an extension or literally just page the radio audio if there is traffic, but then anyone on the band would be able to ring your phone or yell at you from anywhere (could get really annoying if there was a lot of noise in your neighborhood).

They way I have it set up, the radio joins as the owner of the bridge, the local operator joins as the host, and all other callers are lower privilege users. This way a lower privileged user can call in to the bridge and listen with no host logged in, but no TX privileges are granted to them unless a "host" joins and enables TX privileges for them. There will be a web GUI when I get the time, so that on a client by client basis the host can offer TX privileges to other users (this is needed for FOBIC operation).