RF tx and rx problems

[VK4LGW]

I've just received an MMDVM HS Hat which I bought from Florian (just so you know it's not a clone one). I'm trying to connect via the DMR+ Australian server to link to reflector 4800 as that's connected to TG505 which is our national talkgroup.

I can see incoming traffic on the dashboard. It's matching traffic I can see on the vkdmr dashboard.

I'm not able to receive or transmit via this hotspot though.

I'm aware that many people need to change the tx and rx offset. I've done this starting at -1000 through to +1000 in steps of 100, without any change.

I've used the current version using a Raspberry Pi 3B and the beta version using a Raspberry Pi 3B+. (I bought the 3B+ just in case my Pi happened to be faulty.)

I've used other hotspots before, but this is my first time using mmdvm type devices, so in that respect, I'm a newbie. Can anyone offer other suggestions on how I can work out what's happening and how to fix it? I'd prefer to be able to learn about it and work it out myself, but I'm at a loss at the moment.

I don't even know if it's a software or hardware issue. I'm primarily likely to be using this on DMR, but I do have a d-star radio too. I haven't been able to receive or transmit on that radio either, although I haven't gone through the tx and rx offset changes using my d-star radio.

As I sit here and look at it, there's a green led which is steady and the red led marked SVC is flashing at about twice per second. When there's a transmission on TG505 / Refl4800, the orange DMR led lights and on the dashboard.

At the moment, pi-star has the status as listening on TG9/REFL4800 and CC1 which is what I expect. My radio is set to TG9 and works fine with other hotspots. The frequencies I'm trying to use are 439.125 or 439.150 as these are the two internet gateway frequencies used in Australia and recommended in the Australian band plan.

Does anyone have any suggestions?

[is0bzc]

Configuration, general setting, node setting: set public, not private !

[G8SEZ]

Have a look at the live log and see if there is anything showing up there.

If you see any messages about DMR RF queue overruns then it is possible that the ADF7021 is not receiving a clock input from the TCXO and that there is no data flowing between it and the STM32 CPU. The clock driving this goes from ADF7021->STM32 and it doesn't take long for the queue to overflow when data is coming in from the 'net and can't be sent to the RF chip for transmission on the hotspot frequency.

HTH

[VK4LGW]

Configuration, general setting, node setting: set public, not private !

Thanks. I tried that, but no luck. Having said that, this one has never been set up before, so I still need to work out what (if any) offset settings are required, so I'll need to experiment a bit.

I would have thought that if that was the problem, I'd at least be able to hear traffic from the net. I currently can't receive anything, nor can I transmit. On my other hotspot, a similar setting just stiuplates whether the hotspot will handle traffic identied as coming from radios other than mine.

[G8SEZ]

Check that the radio is identified, you should see a version string in the admin page near the Rx and Tx frequency settings

[VK4LGW]

Check that the radio is identified, you should see a version string in the admin page near the Rx and Tx frequency settings

Thanks for replying.

It is. It's identifying as HS Hat v1.4.1
I see traffic on the dashboard, too. Next to the Trx label, the field changes to Tx DMR Slot 2, and then I see Listening DMR. I never hear any audio from my radio, and if I key up my radio, I don't access it either.

Excuse my ignorance, but what is the live log you mentioned in your other post?

[G8SEZ]

It's on the links if you select the admin tab and log in, then open another tab using the live log link.

If the radio is not being clocked but the STM32 is (8MHz clock) then you get the symptoms you mention. The Pi can see the firmware string but not actually hear or transmit RF.

[VK4LGW]

It's on the links if you select the admin tab and log in, then open another tab using the live log link.

If the radio is not being clocked but the STM32 is (8MHz clock) then you get the symptoms you mention. The Pi can see the firmware string but not actually hear or transmit RF.

This was what it logged when I transmitted on a local repeater:

M: 2018-07-18 15:17:30.636 DMR Slot 2, received network voice header from 4800 to TG 9
M: 2018-07-18 15:17:37.377 DMR Slot 2, received network end of voice transmission, 6.6 seconds, 0% packet loss, BER: 0.0%
M: 2018-07-18 15:25:54.254 DMR Slot 2, received network voice header from VK4LGW to TG 9
M: 2018-07-18 15:25:55.411 DMR Slot

That's all that appeared in the last entry. I didn't cut and paste incorrectly.

Nothing appeared in the log when I keyed up on the hotspot frequency.

[G8SEZ]

Try putting it on a busy TG or reflector and see what happens, the first couple of incoming transmissions appear to be OK but then when the STM32 runs out of buffer RAM you will see overruns if they are going to happen.

[KE0FHS]

I still don't fully understand DMRGateway, especially with regards to how it works when mixing BrandMeister and DMR+ (and I don't use DMR+), but I wonder if you need to experiment with this more. As I understand it, if you're linking to a DMR+ reflector, you'd put an 8 in front of the reflector number, for example, 84800. And then you'd talk via TG8. If you're trying to link to a BrandMeister reflector (like 4800), then I think normally you would be using a BrandMeister server and talking via TG9. I'm a bit uncertain when you say you're trying to connect via a DMR+ server, but then linking to a BrandMeister reflector. I could be wrong about that, but it makes me wonder. I have some notes jotted down about DMRGateway in case it might be helpful: https://www.toshen.com/ke0fhs/pi-star-n ... tewaynotes