KE7FNS wrote: ↑Wed Jul 29, 2020 11:17 pm
G8SEZ wrote: ↑Wed Jul 29, 2020 8:40 pm
I have seen a fault like this before when a slightly higher CPU load than normal caused a crash due to the temperature increase flexing the PCB mechanically.
What crashed? The STM32, MMDVMHost, or the communications?
Whats that oscillator used for? I can't find any reference to it in the source code. I only find the TCXO.
If temperature is the issue he could provide some external heat from a hair dryer or heat gun and see if he observes a communications failure.
If he had an identical hat to swap out that would also help to confirm a hardware issue with his board.
How much of a difference is the CPU utilization on a RPi zero W when you run both DStar and DMR simultaneously? and is it really enough to cause a temperature increase like that?
I was referring to something different, a completely different system. Increasing the CPU load by a few percent triggered a problem that was subsequently discovered to be due to a cracked component. The only common point was that this also used an ST CPU. Yes we used a hot air gun to prove it. The 'cracked' component was not obviously damaged even under a microscope, it was probably a manufacturing defect.
The 8MHz crystal is the clock oscillator for the STM32F103 CPU, if there is a problem with that the CPU stops executing code because it has no clock. That definitely can cause a communications failure!
I have a Pi Zero that has both DMR and YSF enabled, it runs a couple of degrees hotter than the DMR-only ones. Doesn't seem much, but such things can occasionally cause a problem.
Mike has ordered another HAT and no doubt will report whether it helps.
If you look at the HS_HAT that the Jumbospot boards were based on you can see that some 3v3 supply filtering was added to them somewhere between v1.2 and the later v1.6 layout. I modified my 3 boards to add this, I don't know how much difference it made but I do know that with my first board the PiStar it was in was quite flaky when I first used it. I made the supply modification as it seemed sensible, but there were a lot of firmware and mmdvmhost changes around this time so I can't be sure what cleaned it up and I didn't keep notes. I do notice that the dual HS_HAT uses a 3v3 regulator supplied from the 5v rail, the 3v3 rail coming up from the Pi board has all of the noise on it generated by the Pi circuitry so this is another sensible change to improve the noise immunity of the whole system. I see that the HS_HAT is being updated to a v2.0 release, it will be interesting to see what has been done to improve it further.
I will be interested to see what Mike finds when he eventually solves this problem.