ZUMspot-RPi Continuous PTT Transmit

General support for the Pi-Star System
Post Reply
User avatar
WB6DNU
Posts: 4
Joined: Sat Jun 30, 2018 8:13 pm
Location: Split between Chattanoonga TN and the west coast
Contact:

ZUMspot-RPi Continuous PTT Transmit

Post by WB6DNU » Sun Jul 01, 2018 7:48 am

Purchased a ZUMspot-RPi kit from HRO at Dayton. Been trying to get the device to broker D-Star but for some reason the ZUMRadio card goes into transmit and stays in transmit continuously. The Power, PTT, and D-Star LEDs stay lit continuously.

Watched all the configuration youtube videos, read various web sites, searched the board here without any success. I followed the setup and configuration instructions closely. I have no idea what is going on with the device and/or whether I hosed something while performing the setup steps.

What strikes me odd is neither Admin > Power > Reboot nor Shutdown resets or turns off the radio board. Not sure why it might reboot or shutdown the Pi without power cycling or killing power to the radio board. Dashboard Radio Info shows TRX as Listening, but both the radioboard LEDs and my TH-D74 show the board transmitting. I have to pull the power cable to reset the ZUMradio board.

Live Logs state:

Starting logging, please wait...
E: 2018-07-01 07:05:31.389 Unable to read the firmware version after six attempts
M: 2018-07-01 07:05:36.390 Opening the MMDVM
E: 2018-07-01 07:05:49.219 Unable to read the firmware version after six attempts
M: 2018-07-01 07:05:54.219 Opening the MMDVM
E: 2018-07-01 07:06:07.050 Unable to read the firmware version after six attempts
M: 2018-07-01 07:06:12.050 Opening the MMDVM

. . . Rinse and repeat.

Dashboard TRX shows the radio "Listening" with a green background. (It aint listening, brother.)
Modes Enabled: "D-Star" (with a green background)
Network Status: "D-Star Net" (with a green background)

The fact that the device is transmitting but web interface indicators are showing green suggest the radio board and Pi are not communicating well; maybe its a hardware issue. Just have no way to tell at this point.

I've managed to get a TH-D74 transmission off before the ZUMspot flips and stays in transmit. Confirmed it on the D-Star Users log page (http://www.dstarusers.org). So apparently when the device decides to listen instead of throw a carrier it passes metrics into the D-Star network as expected.

I do have the TH-D74 configured for duplex with a -zero offset per instructions. (I've also tried it simplex.) Been able to switch reflectors from the radio but the ZUMspot immediately flips into continuous transmit (presumably because it hates me and wants to punish me [a precision technical analysis].)

I've Updated, wiped the SD and reinstalled from a .img using Etcher. Disassembled and reassembled the kit to ensure no pins were bent and everything fit properly. Nothing seems to resolve the issue.

Technical details:

Pi-Star:3.4.13 / Dashboard: 20180623
ZUMspot Firmware: v1.3.7
ZUMRadio ZUMspot-RPi board is Version 0.4

Pi-Star Digital Voice - Configuration:
Controller Software: MMDVHost . . .
Controller Mode: Simplex Node

MMDVM Host Configuration:

D-Star Mode (only): RF Hangtime: 20; Net Hangtime: 20

General Configuration:

Hostname: pi-star
Node Callsign: WB6DNU
Radio Frequency: 431.075.000
Radio/Modem Type: ZumSpot - Raspberry Pi HAT (GPIO)
Node Type: Private
System Time Zone: America/New York
Dashboard Language: english UK (not that it really matters but at least its not French)

D-Star Configuration:

RPT1 Callsign: WB6DNU B
RPT2 Callsign: WB6DNU G
Remote Password: (not worth trying to reverse)
Default Reflector: REF0001 C
APRS Host: euro.aprs2.net (but who cares?)
ircDDBGateway Language: English (UK)
Time Announcements: (enabled)
Use DPLus for XRF: (disabled)

Firewall Configuration

Dashboard Access: Private
ircDDGBateway Remote: Private (Bateway? Really?)
SSH Access: Private
Auto AP: On
uPNP: Off

Wireless Configuration is up and working with fiber access to internet.

Other than taking a mallet to the kit, I'm uncertain how to proceed to further troubleshoot but am willing to give it further effort. Not sure how to "reset" the ZUMradio board or perform lower level diagnostics.

Help?

n9mxq
Posts: 79
Joined: Sun Apr 29, 2018 12:12 pm

Re: ZUMspot-RPi Continuous PTT Transmit

Post by n9mxq » Sun Jul 01, 2018 11:51 am

The only 2 things I can think of would be to bring Pi-star Up to date using SSH, and maybe try to re-flash the modem firmware. If that doesn't fix the issue, you may have gotten a rare bad Zumspot..
Gene in Belvidere IL
Zumspot at home
Jumbospot while Mobile

w7efs
Posts: 70
Joined: Sun Apr 22, 2018 4:26 pm

Re: ZUMspot-RPi Continuous PTT Transmit

Post by w7efs » Sun Jul 01, 2018 4:19 pm

WB6DNU wrote:
Sun Jul 01, 2018 7:48 am
...
M: 2018-07-01 07:05:36.390 Opening the MMDVM
E: 2018-07-01 07:05:49.219 Unable to read the firmware version after six attempts
...
This indicates that the RPi isn't communicating with the zum board. One should first verify the correct choice of Radio/Modem Type, remove the zum board, check the GPIO pins for poor solder connections, clean the contacts and GPIO pins with a good electronics cleaner*, and re-seat the hat. Use a piece of pink anti-static foam to keep the zum board firmly seated in the case if necessary.

* http://amazon.com/gp/product/B000BXOGNI is what I use, and it can often be found in automobile parts stores.

User avatar
WB6DNU
Posts: 4
Joined: Sat Jun 30, 2018 8:13 pm
Location: Split between Chattanoonga TN and the west coast
Contact:

Re: ZUMspot-RPi Continuous PTT Transmit

Post by WB6DNU » Sun Jul 01, 2018 6:57 pm

w7efs wrote:
Sun Jul 01, 2018 4:19 pm
WB6DNU wrote:
Sun Jul 01, 2018 7:48 am
...
M: 2018-07-01 07:05:36.390 Opening the MMDVM
E: 2018-07-01 07:05:49.219 Unable to read the firmware version after six attempts
...

This indicates that the RPi isn't communicating with the zum board. One should first verify the correct choice of modem, remove the zum board, check the GPIO pins for poor solder connections, clean the contacts and GPIO pins with a good electronics cleaner*, and re-seat the hat. Use a piece of pink anti-static foam to keep the zum board firmly seated in the case if necessary.
Solder connections are pristine. Pins are strait, clean, and seat correctly. Boards are securely mounted in a C4LABS case (See: https://c4labs.net/products/zum-pi-case ... ur-pi-zero).
n9mxq wrote:
Sun Jul 01, 2018 11:51 am
The only 2 things I can think of would be to bring Pi-star Up to date using SSH, and maybe try to re-flash the modem firmware. If that doesn't fix the issue, you may have gotten a rare bad Zumspot..
Been there, done that, several times. From SSH:

git clone https://github.com/juribeparada/MMDVM_HS
cd MMDVM_HS
cd scripts
ls
./install_fw_rpi.sh

Also:

sudo pistar-zumspotflash
sudo pistar-zumspotflash rpi

I also wiped and reflashed the SD Card with Etcher using Pi-Star_RPi_V3.4.13_23-May-2018.img.

The radio board does not require I key the D74 for it to trigger continuous PTT from the board. The board will start transmitting after a cold boot (power cycle) on its own after a reasonably brief period of time. This is reproducible. Performing a Configuration > Factory Reset does not reset the radio board which stays in transmit during and after the reset on the frequency I originally programmed. There is also no change during and after performing a reboot after the Factory Default. The device has to be power cycled to clear PTT.

When I perform Configuration > Factory Reset and perform a power cycle, the board idles until D-Star is enabled in MMDVMHost Configuration. This is expected behavior. After enabling D-Star, the board auto-switches on PTT on the default frequency of 438.8.

The issue does not appear to occur in DMR, YSF, or NXDN modes, but does occur in P25, and semi-randomly in YSF2DMR mode. When DMR, YSF, and either P25 or YSF2DMR modes are enabled, the board will scan the modes for about a minute before locking PTT (in P25 if P25 is set; in YSF if YSF2DMR is set). When DMR, YSF, NXDN, and DMR2YSF are set, applying changes appear to lock the web interface. Power cycling and retrying accepts DMR2YSF but disables YSF. That may be expected behavior but it takes several tries and failures to get there.

At this point I'm assuming the board is defective. It happens. I'll pick up another kit from HRO tomorrow and try again. Maybe mix and match boards to see if putting the old board on a new Pi and vice verse changes anything.

News at 11.

User avatar
KE0FHS
Posts: 269
Joined: Wed Apr 11, 2018 8:40 pm
Location: Colorado, USA
Contact:

Re: ZUMspot-RPi Continuous PTT Transmit

Post by KE0FHS » Mon Jul 02, 2018 12:14 am

I'll pick up another kit from HRO tomorrow and try again. Maybe mix and match boards to see if putting the old board on a new Pi and vice verse changes anything.
That's exactly what I'd try next. Since you've already threatened the hotspot with a large mallet, it sounds like you've tried every other troubleshooting step I can think of.

In general, I think the ZUMspot boards are quite reliable (I have four of them and they all have worked flawlessly so far). But as with any electronics, it's certainly possible that there may be a flaw that wasn't easily detectable by the normal quality checks.

Really curious to hear what you learn.

One note:
What strikes me odd is neither Admin > Power > Reboot nor Shutdown resets or turns off the radio board.
It's normal that shutdown alone doesn't turn off the modem board. When you have a modem like the MMDVM_HS_Hat or ZUMspot mounted on a Raspberry Pi, after Pi-Star shutdown is complete, the modem will continue to flash its mode lights (because power is still flowing through the shut down RPi to the modem) until you actually turn off the power to the RPi ... an important thing to keep in mind, especially if you're running on battery! However, I think in normal circumstances a reboot will "reset" the board, though your issue definitely seems outside of "normal." As far as I know, after a shutdown, the only way to restart Pi-Star is to power off and then back on the RPi, and that definitely should reset the board.
73, Toshen, KE0FHS
Playing with Pi-Star (unofficial notes about setting up and using Pi-Star):
http://pi-star.hamnotes.com

User avatar
WB6DNU
Posts: 4
Joined: Sat Jun 30, 2018 8:13 pm
Location: Split between Chattanoonga TN and the west coast
Contact:

Re: ZUMspot-RPi Continuous PTT Transmit

Post by WB6DNU » Mon Jul 02, 2018 4:41 am

Good to know about the modem board power. I assumed GPIO would have been used to unlatch a power connection. I appreciate the clarification.

Just placed an order for two (2) ZUMspot-RPi UHF Kits and cases. Also ordered a couple of 2.4" Nextion displays of Amazon. I expect delivery for everything on the 5th. Will throw them all into a blender, threaten them with the large mallet, and see what spawns forth.

Cheers!

User avatar
WB6DNU
Posts: 4
Joined: Sat Jun 30, 2018 8:13 pm
Location: Split between Chattanoonga TN and the west coast
Contact:

Re: ZUMspot-RPi Continuous PTT Transmit

Post by WB6DNU » Thu Jul 12, 2018 3:42 am

Wanted to circle back and provide an update on the PTT Issue on my ZUMspot-RPi Hat/Pi-Star Zero since receiving the additional kits. The issue is apparently hardware as discussed at the following link:

https://github.com/juribeparada/MMDVM_HS/issues/26

I re-soldered the GPIO connector but there's no significant changes. It worked once in single protocol (DMR) mode but continues to fail and throw itself into continuous PTT when configured with multiple protocols, and changing it back to single protocol mode does not resolve the problem or stop the continuous PTT. Pi is still unable to read the firmware. I'm chalking this up to a defective board and will find it a home in a dead-board friendly home if I'm unable to salvage it otherwise.

Opened the third (unused) ZUMspot-RPi gpio modem and installed it in place of the defective board. So far so good. One thing is certain; running multiple protocols on a simplex hotspot is not a very good idea. Cool that the ZUMspot scans between protocols, but not cool that users cannot change to another talk group or use an alternate radio on an alternate protocol while folks are chatting away on channel and tying up the hotspot's PTT. This is why God created duplex. Not complaining. It's the nature of the beast.

I am going to need to pick up additional radios (and hotspots) so I can play with the other protocols. Fun times ahead!

Post Reply