Unitrunker Release 22

[SCPD]

I had trouble reliably muting / unmuting the DMA Unidens so I removed volume control. The older Unidens have a separate mute command which did exactly what was needed.

The problem with faking any of the Unidens is the program expects a reply like "QSH,OK\r". It will retry the operation up to three times. This stalls any other commands queued.

Does your maxtroller emulate the reply?

 

[GroundLoop]

Oh yes, of course..
It has to fake the MDL response too.
It also sends fake RSSI to PWR requests.
QSH is "OK" for any frequency.

From asking around, I may have to lock out cellular band to comply with ECPA. That's just surreal.


Regarding Tuning commands, if you wanted to make up a protocol to talk UniTrunker to Maxtroller, I'd be all for that.
This will be especially important if you want to combine the bitstream function with the Tune/park function into one board.

Really, that's the way to go -- connect the same Arduino to both the PLL (tuning), the RX Mute, and the Motorola 3600 data feed right off the comparator. No A/D. Then the same radio could be used for receiving audio, or chasing a control channel.

 

[GroundLoop]

If you wanted to combine the responses to Tuning commands, AND the bitstream, we could concoct something like "high bit set for bits, clear for text responses", then pack the bitstream into 7 of each 8 bits.

This will evolve, I'm sure.
Getting more than two A/D channels running on the Arduino is probably not going to happen. Options are:

• Two channels of A/D, 5x oversampled (18,000)
• Three or Four channels A/D, 3x oversampled (10,800 Hz)
• Two channels A/D, plus one digital input (comparator), all at 18,000
• Two channels A/D, plus one digital in, plus one Atmel Comparator, all at 18,000
• Screw it.. one A/D in or one Digital in, plus Maxtroller. You go buy more Arduinos to do more radios.

The AVR has a single analog comparator built-in, which would be wired to take the place of an A/D and runs much faster with no overhead. But that's just one channel, and it's getting complicated.

 

[SCPD]

Really, that's the way to go -- connect the same Arduino to both the PLL (tuning), the RX Mute, and the Motorola 3600 data feed right off the comparator. No A/D. Then the same radio could be used for receiving audio, or chasing a control channel.

Yes. I'm thinking the bitstream could be a separate from the maxtroller. The maxtroller would manage one radio (and need only support one channel). The bitstream could support multiple inputs (at least two). I'm looking at the MCP3202 as a slicer shield ... but that's another discussion.

If the baud rate will support it - the binary data could be streamed as ASCII. That would allowing mixing command I/O with data. Traditional ASCII delimters like CR/LF or STX/ETX could be used. Parsing command responses vs. streaming data would be easy.

An ASCII hexadecimal digit could convey 4 bits of data in the space of 8 bits - so you lose some top end capacity. If you're sample at 18 khz ... that's 36 kilo bits (for two channels) using 90 kbps (including start and stop bits). As previously noted, tune commands would implicitly shut off decoding so the two really would not compete for bandwidth. The maxtroller - supporting only one channel - would only use 45 kbps of 115.2 kbps available.

 

[GroundLoop]

If the (one-channel) Maxtroller were to send unrequested ASCII data, would that confuse UniTrunker today? I'd hate to overflow some input buffer expecting only Uniden responses, for example.

Sending it as ASCII wouldn't be hard at all.

R2:f16f97be068104f336bd345e86749391<cr>
R2:79e044b90209a32f92e250c3310d7fba<cr>
R = Raw binary, undecoded
2 = Two level

So it would receive tuning commands, respond to MDL, PWR, QSH, etc, all the while blabbering on about samples.

Really, this is kindof a novelty, since M36 seems to be a well-solved space already. I mostly just want to get good Rx audio, and free up my audio inputs for recording.

It's much more interesting for P25 Audio, where scanners are expensive while surplus radios are still cheap. Then, P25 control channels without audio cards or pre-processing scanners. You get the idea.

 

[GroundLoop]

Man, I'm going nuts with this MaxTrac 820 "B5" radio.. I simply can not get the Audio to unmute!

I've cut the RX MUTE and PA MUTE off the CPU altogether, tried all combinations of signals there, but can't get any sound at all from the speaker.

I suspect my RX MUTE is working fine (unmuted) as I see audio on VC TOP.. it's likely the PA is just not turning on. Arg!

The discriminator tap is fine, but there's no good way to mute it that I can see. I wonder if UniTrunker could pass-through audio and whack the volume control to mute it when there is no signal? Niche application, I know, but would fit with recording audio and tagging it.

 

[Bote]

Man, I'm going nuts with this MaxTrac 820 "B5" radio.. I simply can not get the Audio to unmute!

I've cut the RX MUTE and PA MUTE off the CPU altogether, tried all combinations of signals there, but can't get any sound at all from the speaker.

Did you jumper the two accessory pins on the rear that complete the circuit to the speaker, in place of an external speaker?

Bote

 

[GroundLoop]

Yup yup. When the CPU was in control, it was able to 'beep' the alert out of the speaker, and I did occasionally get blurts of PA through the internal speaker.

I'm starting to think I blew something in the PA switching (Q509), since I'm driving the same signals as the CPU with no effect.

But hey, we're putting tuning under UniTrunker control, tapping the data to feed bits, isn't the next logical thing to put continuous Audio under UniTrunker muting/recording/routing control?
Work with me here..

 

[GroundLoop]

Otherwise, we might have to ditch the Trunking-only radios and stick to ones that have at least one Conventional channel to park on for CSQ.

 

[SCPD]

If the (one-channel) Maxtroller were to send unrequested ASCII data, would that confuse UniTrunker today?

I think it would silently ignore the unknown messages. The trailing carriage return would make it compatible from a parsing perspective. The code is written such that strings that don't match an expected response to the last command sent (top of the stack) are ignored. I'd need to test to be sure.

Uniden did something very annoying with the inline CC data. The P25/M36/ED/LTR messages are prepended with a line break instead of a trailing line break. It's the dumbest thing. A CC message followed by another CC messages gets a trailing line break. However, a CC message followed by a command response gets no delimiter between the two. You have to guess where the CC message ends and the response begins. With annotated output, this is next to impossible.

As the owner of a BCD996XT, I have expressed my dissatisfaction to Uniden.

If you emulate Uniden style M36 messages - by all means use a trailing line break.

isn't the next logical thing to put continuous Audio under UniTrunker muting/recording/routing control?

I have so far managed to avoid waveOut mixer controls. Supporting this would take some work. It would have to compete with a long list of enhancements. For digital audio (from a non digital radio), you do want the audio routed through the PC - but that's another discussion.

 

[SCPD]

Here's a screenshot of the UI updated to support streaming. Most settings don't really apply to this type of receiver. It's also missing the ability to select sample rate and channel. It's stuck on channel 1 at 18khz sampling.

 

[GroundLoop]

Awesome!
Is it easy to extend to 2ch (ABABABAB) bytes?

I wouldn't use the M36 format in Arduino because it implies pre-digested M36 data. I'd rather leave that to UniTrunker for superior phase tracking and versatility. I don't think it's possible to interleave two (unrelated) M36 streams on one COM port either? If there is, let me know as it would be an interesting project to see if Arduino can chunk them in real-time.

The Uniden line-termination behavior sounds more like a bug than an intentional design. At least, I would hope so! Horrid.

I'd be all for you making up your own preferred formats. Let me know what you decide and the Arduinos will be flashed in a sec.

 

[SCPD]

Is it easy to extend to 2ch (ABABABAB) bytes?

That will take more effort. The program supports sharing audio input devices across signal receivers to support left/right channel audio. I'd have to do something similar here for serial ports - something I've never needed (except maybe for proper CI/V device chaining) before.

 

[SCPD]

The Uniden line-termination behavior sounds more like a bug than an intentional design. At least, I would hope so! Horrid.

Speak of the devil.
http://forums.radioreference.com/tr...new-systems-1-edacs-system-4.html#post1566702

 

[GroundLoop]

I'm starting to think I blew something in the PA switching (Q509), since I'm driving the same signals as the CPU with no effect.

In keeping with the spirit of this project, I did my first ever SMT repair and stole a donor transistor from Q801 (ALARM) to replace Q509. It works! I love these boards (and these docs)!

I can now unmute audio and enable the PA from the Arduino, whenever UniTrunker is "unparked".
This means the 2-Trunk radios are fully functional as a Maxtroller voice receiver. More over in the other thread..

 

[GroundLoop]

How does "Chase" work in UniTrunker?

I would love to see UniTrunker receive the Control Channel bitstream from MaxTroller, while retuning it as needed to follow the Control Channel. To do this, I'm trying to emulate the MOT stream from Uniden, as well as QSH of course.

A curious problem is "where to start". The MaxTroller doesn't tune anything until told, and it seems UniTrunker expects the initial control channel to be "already tuned". Ideas?

 

[SCPD]

One inelegant hack is to set the park frequency to the active control channel. I'm overdue to add a point and shoot mechanism where you'd select an idle "both" or inline receiver to begin monitoring.

 

[GroundLoop]

It doesn't seem to tune to the Park frequency on Receiver startup. I could be missing something, but it doesn't park until after the first QSH. It goes from MDL to PWR and waits for CCh data?

When UniTrunker opens the COM port, it resets the Arduino (by design, to allow the bootloader to run..), so it always starts from a a "Hi Hello" state.

I'm hardcoding the first tune-to control channel now, but that's madness.

 

[SCPD]

It doesn't seem to tune to the Park frequency on Receiver startup. I could be missing something, but it doesn't park until after the first QSH. It goes from MDL to PWR and waits for CCh data?

Park is a voice following feature. Set the role to Voice, start/stop the receiver to place it on the park frequency. Flip the role to Signal and re-start the receiver for decoding. Did I mention this was an inelegant hack?

 

[GroundLoop]

Ahh, the sheer inelegance is just now starting to sink in.