forum.pistar.uk

G8SEZ wrote: ↑Wed Jul 18, 2018 3:50 pm 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.

I'm not sure how to do that yet. I'll wait until the local TG is busy. It's 2 am here now, so there's no traffic.

KE0FHS wrote: ↑Wed Jul 18, 2018 3:50 pm 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

Here in Australia 4800 is a DMR+ reflector. Most repeaters are on the VK-DMR network which uses DMR-MARC style technology. My understanding is that Brandmeister is quite active over here, but the majority of the traffic it carries is only via hotspots. I've registered with Brandmeister, but haven't spoken on it. My plan would be to get the DMR+ side of it working first, because that's the network I'm familiar with.

Here in Australia 4800 is a DMR+ reflector.

In that case, when you're using DMRGateway as your DMR master (in the DMR Configuration section of Pi-Star), I'm pretty sure you need to use 84800 and TG8. The way I understand it, that's how DMRGateway distinguishes between Brandmeister's 4800 reflector and DMR+'s 4800 reflectors. If you just use 4800 with no prefix (and TG9), that indicates BrandMeister to DMRGateway. DMR+ uses the prefix 8 and TG8, and XLX uses the prefix 6 and TG6.

VK4LGW wrote: ↑Wed Jul 18, 2018 4:04 pm

G8SEZ wrote: ↑Wed Jul 18, 2018 3:50 pm 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.

I'm not sure how to do that yet. I'll wait until the local TG is busy. It's 2 am here now, so there's no traffic.

Sure, I expect that if you see a few transmissions then you will start to see DMR RF slot queue overflow messages.

Coincidentally I have just replaced the TCXO on one of my MMDVM_HS HATs which was exhibiting this fault, it now appears to be fine. Some people have reported that the Chinese-built boards sometimes have poor quality TCXOs so I bought a few FOX924 TCXOs to deal with this. I am hoping it will improve the off-frequency aspect too as these TCXOs are supposed to be within 1.5ppm but often are not.

G8SEZ wrote: ↑Wed Jul 18, 2018 7:51 pm

VK4LGW wrote: ↑Wed Jul 18, 2018 4:04 pm

G8SEZ wrote: ↑Wed Jul 18, 2018 3:50 pm 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.

I'm not sure how to do that yet. I'll wait until the local TG is busy. It's 2 am here now, so there's no traffic.

Sure, I expect that if you see a few transmissions then you will start to see DMR RF slot queue overflow messages.

Coincidentally I have just replaced the TCXO on one of my MMDVM_HS HATs which was exhibiting this fault, it now appears to be fine. Some people have reported that the Chinese-built boards sometimes have poor quality TCXOs so I bought a few FOX924 TCXOs to deal with this. I am hoping it will improve the off-frequency aspect too as these TCXOs are supposed to be within 1.5ppm but often are not.

That's exactly what happened. It was fine for the first few overs of someone's conversation. Then I got the overflow errors.

VK4LGW wrote: ↑Thu Jul 19, 2018 4:18 am

G8SEZ wrote: ↑Wed Jul 18, 2018 7:51 pm

VK4LGW wrote: ↑Wed Jul 18, 2018 4:04 pm

I'm not sure how to do that yet. I'll wait until the local TG is busy. It's 2 am here now, so there's no traffic.

Sure, I expect that if you see a few transmissions then you will start to see DMR RF slot queue overflow messages.

Coincidentally I have just replaced the TCXO on one of my MMDVM_HS HATs which was exhibiting this fault, it now appears to be fine. Some people have reported that the Chinese-built boards sometimes have poor quality TCXOs so I bought a few FOX924 TCXOs to deal with this. I am hoping it will improve the off-frequency aspect too as these TCXOs are supposed to be within 1.5ppm but often are not.

That's exactly what happened. It was fine for the first few overs of someone's conversation. Then I got the overflow errors.

Right, so you could try reflowing the connections to the TCXO and if that doesn't help it would need a TCXO change. Be careful to pick a package size that fits your PCB, I think the 'authentic' PCB has pads for a 3x2mm part whereas the Chinese variants can accommodate these or the larger 5x3mm package.

It might help people diagnose this if the MMDVM_HS firmware output a warning message that the TCXO may have died if these overflow errors occur.

Thanks.

I contacted the supplier. He said that if reflowing doesn't work, he'll exchange it.

I've had to google "reflowing" to know what that meant. I initially thought it was soldering with a soldering iron. But when I looked at the PCB, I realised that's not the case. To be honest, I don't even know which component is the TCXO. I'll need to buy a magnifying glass to read them.

I'm a shift worker and it would be several weeks before my work roster will allow me to meet up with anyone who might likely be able to help. Although I'd like to be able to say that I completed the repair myself (along with your capable suggestions and advice, of course) but it may be more practical to exchange it. The worst part is that it has to go all the way back to Germany for what might just be a tiny little fault.

VK4LGW wrote: ↑Fri Jul 20, 2018 1:55 am Thanks.

I contacted the supplier. He said that if reflowing doesn't work, he'll exchange it.

I've had to google "reflowing" to know what that meant. I initially thought it was soldering with a soldering iron. But when I looked at the PCB, I realised that's not the case. To be honest, I don't even know which component is the TCXO. I'll need to buy a magnifying glass to read them.

I'm a shift worker and it would be several weeks before my work roster will allow me to meet up with anyone who might likely be able to help. Although I'd like to be able to say that I completed the repair myself (along with your capable suggestions and advice, of course) but it may be more practical to exchange it. The worst part is that it has to go all the way back to Germany for what might just be a tiny little fault.

Have a look here, there is a picture of the board a little way down the page:

https://github.com/mathisschmieder/MMDV ... ree/master

the TCXO is labelled X1. It's in the centre of the board towards the top where the HAT connector is.

It's certainly very small, my aged eyesight struggles but luckily I have access to good magnification kit at work. If you do redo the solder joints it will need a very small iron tip and some very thin solder and take care not to short anything, there is *just* enough pad showing to do it. The alternative is using a hot air pencil but as you say once you have found someone with the right equipment it's going to need to fit in with your shifts.

I am a bit surprised that the board wasn't fully tested before dispatch, but I suppose that a slightly dry joint could cause this and maybe they just checked that the modem was recognised. Perhaps they could send a tested replacement that you could check and then return the faulty one? Just a thought.

Hope you get this sorted soon.