P25RX Firmware Updates / Testing

[btt]

Aah. System RESET. I saw you said "power cycle", and I just restarted the Btconfig software. @480MHz now. Thanks.

Thanks. Did P2 work for you at new default of 400 MHz? That is the main question I'm looking to answer.

 

[btt]

There is another update to the firmware. There are some MCU clock-frequency-dependent delay functions in the firmware. Version 2021-07-15_0609 compensates for differences when running @400 vs @480 MHz. This should result in faster frequency changes between control and traffic channels.

 

[Cheeseburgers]

Thanks. I assume it also worked ok on P2 running at 400 MHz for you?

I will say this... running at 480mhz has drastically improved decode at my office... the tricky 700mhz site that the G4 and SDS100 had issues with, and the 325p2 was pretty much deaf on.

 

[Cheeseburgers]

Was the prior default 480mhz?

 

[btt]

Was the prior default 480mhz?

Yes.

 

[Cheeseburgers]

Todd, FWIW the audio is glitchy and poppy for me @400 on a V unit. I am going back to @480 running 1617... far better audio.

 

[btt]

Todd, FWIW the audio is glitchy and poppy for me @400 on a V unit. I am going back to @480 running 1617... far better audio.

That is certainly not what I wanted to hear. Thank you for testing and reporting on it.

 

[Cheeseburgers]

That is certainly not what I wanted to hear. Thank you for testing and reporting on it.

edit: BTW, did you try it at 400 MHz with the latest release of 2021-07-15_0609?

yep, that was where i was getting the clipping audio and hanging on TGs, when switched back and set back to 480 it is a noticeable difference... wish I had better news.

 

[Mike_G_D]

I have the "V" version with 7-15_0609 and am trying the 400 MHz clock speed now. Mixed system with P1 and P2. Will let you know how it goes. By the way - just a thought, would the clock speed change affect the IF bandwidth DSP calculations? If so and not compensated for maybe that could cause the choppy audio Cheeseburgers mentioned. If not then my only other guess would be the audio processing. I'll see how it goes for me and report results.

 

[btt]

I have the "V" version with 7-15_0609 and am trying the 400 MHz clock speed now. Mixed system with P1 and P2. Will let you know how it goes. By the way - just a thought, would the clock speed change affect the IF bandwidth DSP calculations? If so and not compensated for maybe that could cause the choppy audio Cheeseburgers mentioned. If not then my only other guess would be the audio processing. I'll see how it goes for me and report results.

Mike, that is a good thought, but the IF bandwidth is an analog filter on the ASIC. The I/Q sample rate is determined the ASIC clocks which are independent from the MCU clock rate. The audio clock is on the MCU, but should be identical rates for 400 MHz and 480 MHz. If there is an issue running at 400 MHz, I suspect it will be execution time for FEC or audio synthesis for P2 (working well for P1 here).

 

[Mike_G_D]

Well, so far, 400 MHz is working ok for me.

So how do the P25 channel filters settings work? I assumed that they are DSP based after the fixed bandwidth IF filter to allow for the settings changes. The hardware filter would be fixed unless you have more than one choice that is selectable but I recall you saying long ago that it was only one.

 

[btt]

There are are analog filters before the A/D converters. They are variable (I believe they are switched capacitor type). The ASIC also performs FIR filtering and decimation after A/D conversion (variable sample rate). The quadrature samples from the ASIC are re-sampled with a polyphase FIR filter in software on the MCU before passing to the symbol synchronizer (which is also poly-phase, multi-rate type). The BW was fixed in code in earlier firmware. Recently, I added a user-configurable option on the advanced tab.

 

[Mike_G_D]

There are are analog filters before the A/D converters. They are variable (I believe they are switched capacitor type). The ASIC also performs FIR filtering and decimation after A/D conversion (variable sample rate). The quadrature samples from the ASIC are re-sampled with a polyphase FIR filter in software on the MCU before passing to the symbol synchronizer (which is also poly-phase, multi-rate type). The BW was fixed in code in earlier firmware. Recently, I added a user-configurable option on the advanced tab.

And yes! I did actually understand what you said (though don't ask me to build DSP code for those FIR's!) and I did a nice "DOH!" head slapping moment when you mentioned switched cap filters - dang it has been awhile but yes, I completely forgot about those and tend to think in higher frequency IF's (kinda still stuck in late 90's hardware RF mode) so had relegated them to audio mostly in my head. But with these SDR and hybrid designs and very low frequency IF's they can work.

Many thanks for the patient and clear explanation!

And, just for the record, still no issue with 400 MHz clock at my end for either P1 or P2 traffic.

-Mike

 

[btt]

And, just for the record, still no issue with 400 MHz clock at my end for either P1 or P2 traffic.

That is really good news! Now I'm leaning toward FEC execution time being a possible explanation why Cheeseburgers is having audio issues with the 400 MHz system clock.

 

[Cheeseburgers]

I just re-installed the newer FW to confirm what I had experience Todd.. it is still there, very choppy audio in 400mhz, not in 480 on my V unit... This is again in a very tricky area with high simulcast distortion... back in 480 on the old FW its much much better.

 

[btt]

I just re-installed the newer FW to confirm what I had experience Todd.. it is still there, very choppy audio in 400mhz, not in 480 on my V unit... This is again in a very tricky area with high simulcast distortion... back in 480 on the old FW its much much better.

Thank you. I found that DMR was choppy audio with the 400 MHz system clock. I was able to further optimize to get it sounding good. When you have a chance, can you test 2021-07-15_1132 and see if that takes care of the choppy P2 audio for your location? I appreciate the help.

 

[Cheeseburgers]

testing now

 

[Cheeseburgers]

400 still no good, for this particular system, back at 480 in 1132, again much better at 480. Not sure why... if you need me to take a video I can.

 

[shirsch101]

So how do I tell if I have a V or Y chip? I have access to 700 and 800 MHZ P2 and will test today.

 

[btt]

400 still no good, for this particular system, back at 480 in 1132, again much better at 480. Not sure why... if you need me to take a video I can.

I believe it. No need for a video. Just realized It could be the channel filter settings. A higher bandwidth will produce a higher sample rate and more work for the MCU. What are the filters set to on the advanced page? I had it set to 14.2 kHz for the time I've been monitoring. A setting of 12.4 kHz would be a good test to see if there is improvement if you don't already have it set to that.

So how do I tell if I have a V or Y chip? I have access to 700 and 800 MHZ P2 and will test today.

Thank you. On the console, type in the command 'mcu_ver'.