Portsdown 4 PTT Bounce

[G6MNJ]

I have a Portsdown 4 latest firmware, Pluto, plus various driver amps to illuminate the 1.6m dish here. When I use IPTS in a strange thing happens that randomly when TX is selected the PTT line on the GPIO connection pin 40 goes high 3.3v which in turn fire the relay for the transmitter stages then within a second the PTT line drops back to 0v. The software still tells the raspberry Pi screen that he TX mode is selected and indeed it will switch back to RX if tapped.

Often a reboot or power down is required to clear this state as once it has done the PTT bounce it never stays on more than a second. FEC, Sym Rate Modulation don't seem to make a difference but I am testing it with S2QPSK 333k 2/3 on 13cm on QO-100.

Now if I select local testcard and not IPTS works perfectly. The IPTS is created with ffmpeg and can be 'seen' perfectly by the IPTS monitor.

Any help and suggestions would be appreciated.

73 Paul G6MNJ

[G6MNJ]

UPDATE

It does it when running its internat test card despite my initial comments above....

[G6MNJ]

Could my problem have something to do with ffmpeg not running... code taken from pluto_ptt.sh?? Maybe I should increase 1 second to 2 - what do you guys think?

# Check again after 1 second, to make sure that PTT hadn't just been cancelled
# If not running cancel PTT
sleep 1
if ! ((pgrep -x "ffmpeg" > /dev/null) || (pgrep -x "dvb_t_stack" > /dev/null))
then
gpio -g write $PTT_BIT 0
fi
fi

[G8GKQ]

Hi Paul

I'm just catching up on Forum replies after 10 days away.

You don't say how the Pluto is connected to your Portsdown. However, it sounds as though there is some problem causing the Portsdown to be unable to establish an rtmp connection with the Pluto.

What happens when you select transmit is that Portsdown starts an 8 second timer to delay the PTT. It then (while the timer is running) starts ffmpeg which requests an rtmp connection with the Pluto. If the Portsdown can't create that connection ffmpeg terminates itself. Then when the 8 second timer is complete, it turns the PTT on. After a further 1 second, it checks that ffmpeg is still running; if not it turns the PTT off.

I suppose that a better implementation might be to never even turn the PTT on if ffmpeg is not running, but this would not help in your case - the root cause is probably the failure to create an rtmp connection between the ffmpeg instance in Portsdown and the rtmp client being run by the Pluto.

Obvious suggestions:

• Check the Pluto firmware
• Connect the Pluto to the Portsdown by a known reliable USB lead
• Check the Pluto is properly powered (monitor the 5v rail with a scope as you go to transmit)
• Check the Portsdown is properly powered

The Pluto needs rebooting after this sort of rtmp problem - so that is probably where the issue is.

Dave

[G6MNJ]

Thamks for your reply - can I clarify something please?

Pluto is connected to Pi USB 3 port.

Check the Pluto is properly powered (monitor the 5v rail with a scope as you go to transmit) - It gets its power from the Portsdown - should I supply it from a seperate PSU?

Check the Portsdown is properly powered - 3A 5v PSU in place so that should be ok?

73 Paul

[radiogareth]

Possibly related....I have two Portsdown4's and one has been very fussy recently about keeping the Pluto connected. The PSU was set to 5.2 volts. Turning it down to 5.00 (on the RPI header pins) seems to have removed any unreliability. The Pluto is connected via an ANKER brand short cable into USB3.

My other PD4 shows 5.25V on its header, but the Pluto is on a 1m long Anker brand lead. This unit is also very reliable... ?? Think I read somewhere that the Pluto was very fussy about its 5V value. Maybe worth checking inside the Pluto Blue box to see what its actually getting....

Gareth

[G8GKQ]

Hi Paul

What matters is the voltage that the RPi 4 actually receives during load peaks. It's generally the cable and connectors that cause more problems than the PSU itself. So measure the voltage between GPIO pins 4 and 6.

I always power the Pluto from the RPi USB. I have heard reports of problems caused by using separate PSUs - mainly caused by differences in ground potential between the 2 PSUs.

Dave

[G6MNJ]

Well problem solved the ffmpeg process running on my OBS PC was making the CPU hit 100% and it was that causing the PTT to drop.

I now have a hardware H264/H265 encoder and all is working as expected.

73 everyone
Paul G6MNJ