UT and BC250d

[Liverdog]

Rick:

Are you open to coding in specific COM control codes for the BC250d? The reason I ask is that I'm a having specific issues with the commanding of the scanner as the voice decoder where I think that a couple extra commands could clean things up... I've been using PORTMON to watch the COM activity and either UT is interpreting the scanner type up front and forcing commands specific to that scanner, or UT has common commands for scanner families - I'm not sure which.

In any case, the most troublesome problem for me is that for some reason just sending the "RFXXXXXXXX" command without explicitly specifying the modulation type is causing the BC250d to sometimes go to "AM" with P25 decoding, the effect of which is I hear decoded AND undecoded ASTRO at the same time.

Secondarily, I'd like to be able to see the effect of not sending the MUA command with the Park Mode types. What I'm hoping is that the "silence bits" that are sent in the ASTRO voice frame won't be decoded as audio hash in the 1/2 second before the real voice starts.

I'm not what would help you best or even if you're interested, but I'd be willing to invest the time to work it out.

 

[AZScanner]

What would really be helpful here is if the program issued a DV command after switching to the voice frequency and only unmuted the scanner if that command reported back DVN - meaning Digital Voice On. I've added this to the digital close call app I'm writing for the older unidens. It does cut off a little bit of the transmission sometimes but it was necessary because sometimes the signal is just pure crap and won't decode, resulting in the virtual equivalent of nails on a chalkboard to my wife. Gotta keep the peace.

As for RF going to the AM band, that's just odd. RF should just tune the commanded frequency and use the scanner's default modulation for the band. I've never seen it tune an 800MHz frequency in AM mode for example. If you would, can you post the log of commands that were sent out up to and including when this happened? I bet there's something in there causing this besides just the RF command.

-AZ

 

[SCPD]

What would really be helpful here is if the program issued a DV command after switching to the voice frequency and only unmuted the scanner if that command reported back DVN - meaning Digital Voice On. I've added this to the digital close call app I'm writing for the older unidens. It does cut off a little bit of the transmission sometimes but it was necessary because sometimes the signal is just pure crap and won't decode, resulting in the virtual equivalent of nails on a chalkboard to my wife. Gotta keep the peace.

Thanks AZ. I'll look into this. I'm wondering if the delay between the two commands is sufficient time for the radio to make the determination.

As for RF going to the AM band, that's just odd. RF should just tune the commanded frequency and use the scanner's default modulation for the band. I've never seen it tune an 800MHz frequency in AM mode for example.

LD might be parking on an airband frequency or parks the radio in scan mode with an AM channel in one of the active memory banks. If so, that means the listen mode setting isn't working.

The real problem is I don't have access to any of the early digital capable Unidens so I don't have a convenient way to play with the extra commands those models provide.

If you would, can you post the log of commands that were sent out up to and including when this happened? I bet there's something in there causing this besides just the RF command.

The Tuner app provides a log - but Unitrunker does not. LD can fire up Tuner - plug in a frequency and hit the tune and scan buttons a few times. The full log can be viewed by selecting [H]elp -> [A]bout ... and press the [View Log] button.

 

[Liverdog]

I can capture the bi-directional COM traffic in a text file and post it. Really, without any other knowledge it would appear that the commands are working by looking at the COM traffic. I do see from time to time an ERR when using the Memory park (see approx line 30 in the LD_Mem_park.txt).

As far as parking, I've tried different variations of Mute, Frequency, Memory with the same results. In my experiements I've always parked on a blank memory channel (memory 1000, freq 0000.000), or an 800 MHz frequency in the case of Frequency.

The appearance of the AM mod/ P25 combination seems to be random, but it will typically start and continue for about a dozen transmissions then sudenly return to NFM/P25.

I suggest opening these files in your fav spreadsheet prog... Makes it easier to read...

P.S. while watching the display on the BC250d while typing this post I notice that scanner is also going to FM/P25, so it appears that it rotating through the three possible mod combinations (AM/P25, NFM/P25, FM/P25). "FM" meaning wideband FM.

 

[AZScanner]

What's up with the KEY07 command (the hold button)? I assume that is how it is returning to the park channel? If so, instead I recommend using the RF command and going to something like 856.0000 or something, whatever the user has determined to be the park frequency. Then have the program issue a KEY00 as a bit of cleanup on exit to resume normal scanning.

If you need to force the modulation mode, the RM command will do that. Just issue RM NFM (or whatever mode you want) after tuning. I think it'll work after issuing an RF but am not at home right now to try it. Give it a shot and see.

I would love to see Uniform released as a compatible DLL that I could call in VB to create a nice nifty front end app that would trunktrack with a single scanner. Sigh... maybe someday.

-AZ

 

[SCPD]

There's something weird here ...

0 0.00003073 Uniform.exe IRP_MJ_WRITE Serial0 SUCCESS Length 6: KEY07.
1 0.11734899 Uniform.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
2 0.02336135 Uniform.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS

There is no response to the KEY07 ... I don't remember if the radio is supposed to answer here.

3 0.00003799 Uniform.exe IRP_MJ_WRITE Serial0 SUCCESS Length 11: RF08579375.
4 0.04630644 Uniform.exe IRP_MJ_READ Serial0 TIMEOUT Length 3: OK.

The RF command is OK'd right away.

7 0.00002738 Uniform.exe IRP_MJ_WRITE Serial0 SUCCESS Length 4: MUA.
8 0.03097293 Uniform.exe IRP_MJ_READ Serial0 TIMEOUT Length 3: OK.

As is the un-mute command. But wait ...

9 0.01102682 Uniform.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
10 4.57029678 Uniform.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
11 4.68694764 Uniform.exe IRP_MJ_READ Serial0 TIMEOUT Length 3: OK.

What the heck is this OK doing here like 9 seconds later? OK in response to what?

It's consistent throughout the rest of the log.

-rick

 

[AZScanner]

The radio should answer OK to a KEY07.

I see 3 commands issued in the example quoted above and 3 responses. Therefore, I would guess, by reading this, that your routine that writes to the scanner isn't waiting for a response before it issues another command. Instead, it looks like you're using interrupts to read from the buffer whenever the scanner is done responding. That will cause exactly what you see in the log above.

In the code I've written, I always wait after sending a command for the full response to come back from the scanner before the program does anything else. The reason why is because the scanner replies so slowly (compared to the speed of your computer) that it's really easy to get out of sync with the scanner's responses, as you can see. If you're using a low baud rate and a speedy computer, the problem really becomes evident.

Now in the case of this current flavor of Unitrunker, I really don't see it caring if the scanner responded with "OK" or "ERR" or even "WTF" so if you wanted to keep your code running fast then just flush the comm buffer before issuing a command each time. The scanner will obey even if you don't let it get a word in edgewise.

-AZ

 

[SCPD]

The radio should answer OK to a KEY07.

I had to refer back to the code. It sends a KEY01 or KEY07 depending upon the model detected. It expects one of the following before moving on to the next command: OK, NG, or ERR. It will wait 250 ms before re-issuing the command w/ 3 tries max before aborting. That's how the code is written - which doesn't match LD's log examples so I don't know what is going on.

I see 3 commands issued in the example quoted above and 3 responses. Therefore, I would guess, by reading this, that your routine that writes to the scanner isn't waiting for a response before it issues another command. Instead, it looks like you're using interrupts to read from the buffer whenever the scanner is done responding. That will cause exactly what you see in the log above.

Actually - it's overlapped IO driven by a separate thead, a small state machine, and a FIFO command queue. The carriage return is set as the event char - which works nicely with Unidens.

In the code I've written, I always wait after sending a command for the full response to come back from the scanner before the program does anything else. The reason why is because the scanner replies so slowly (compared to the speed of your computer) that it's really easy to get out of sync with the scanner's responses, as you can see. If you're using a low baud rate and a speedy computer, the problem really becomes evident.

If you look at the time difference between the READ's and the WRITE's, you will see a small number because the program is doing exactly that. It is waiting for a response before sending the next command.

Now in the case of this current flavor of Unitrunker, I really don't see it caring if the scanner responded with "OK" or "ERR" or even "WTF" so if you wanted to keep your code running fast then just flush the comm buffer before issuing a command each time. The scanner will obey even if you don't let it get a word in edgewise.

I've made some effort for the program to tolerate and recover from someone unplugging the serial port cable which is part of the reason for paying attention to the responses.

 

[Liverdog]

Okay, more on this. I see what is happening... I have memory channels in the scanner populated with all sorts of NFM, WFM, and AM frequencies from when I use it without UT.

UT is not correctly processing the command to park on a memory channel or frequency most of the time. Instead the scanner is "scanning" around all its programmed memories. When UT commands the scanner to RFXXXXXXXX to a frequency it stops scanning momentarily on a particular memory channel, "RF's" the correct frequency, but takes on the modulation of whatever is programmed in that memory slot. So, if it stops on a civilian air frequency (memory location) programmed with AM, AM is what I get. All the while I see the memory channel location flashing as it does in scan mode. As soon as there is no more trunking activity in UT, the scanner goes back to scanning around the memory channels.

I have tried manually turning the scanner off, then pressing HOLD, starting UT, but with the same results above.

Thanks

 

[SCPD]

Hi LD;

Are you using "Park on Frequency" instead of "Park on Scan" ?

Also, under [L]isten options - does the program give you a "Park Mode" choice of anything beside "Auto"?

-rick

 

[Liverdog]

All I have is "Auto". Space bar and arrow keys won't change it. I don't use the "Scan" option. I only have tried the other options.

I want to take back what I said earlier. I entered the commands manually through Hyperterminal -those that I saw UT output in the log file- to see the effect in slow motion.

The RFXXXXXXXX command, besides entering the frequency, seems to put the scanner in a suspended state where it is waiting for another command and the channel number flashes. This is what I thought was scan. When the KEY07 is entered, it causes the scanner to advance to the next memory location. So, to me, the flashing memory location followed by an advancing number looked like "scanning".

Now, the effect, and problem still exists (ie the mixed modulation) it's just that I have a better understanding now of what I was seeing.

 

[SCPD]

Hmmm. The purpose of the KEY07 was to make darn sure the radio was in manual mode.

I can move the KEY07 to the initial connect sequence and issue a new one only to break out of SCAN (for Park on Scan) if so selected. That will stop the nonsense of slowly walking through channel memory. The alternative is to query the radio's state with the MD command. The MD command is so different for every model so I don't want to mess with it unless necessary.

Sorry folks ... programming for a radio I don't have is a pain.

LD - I'll follow up with you on this when I have some time. As AZ can confirm, I'm a little busy right now.

 

[Liverdog]

No problem. Hope it helps.