BATC Forum

Hello all
I've modified a new Pluto so the ground mod and 0.5ppm TCXO are fitted pictured. The Pluto did a SATSAGEN spectrum analyser and tracking generator sweep on a coax cable from 50MHz to 6GHz just fine with DATV firmware. It transmits a signal in FM with the Langstone that shows up on my spectrum analyser on e.g 2m, 70cm and 23 cm bands. The DATV firmware info page shows up no bother. All attempts to produce a DATV signal in Pluto output in Portsdown 4 have come to nought. Should it just work out of the box or is there a hidden switch? I'd better look for a 40MHz signal with my oscilloscope no it's all in doubt.

Can one load DATV firmware on my second Pluto which is unaltered and then go back to AD firmware later? I've no idea what normal behaviour is like for the Pluto option.

73
David M0YDH

David

When you say DATV Firmware, which firmware do you mean?

Don't worry about the 40 MHz oscillator mod - if it worked with Langstone, then that is OK.

Try a reboot of the Pluto (Menu 3, Pluto Config, Rebbot) and then try transmitting 437 MHz DVB-S2, QPSK, H264, 333 kS, FEC 2/3, Testcard. Safe options.

Dave

Hello Dave
F5OEO firmware .frm file per Mike's instructions is in use. Is there any other DATV firmware?
All this was done with the Pluto plugged into a USB3 port. I tried the prescribed settings and no DATV signal rose out of the -70 DBm noise floor. The only difference before was 1/2 FEC. I rebooted the Pluto from the menu but no change no signal. Langstone FM with a mouse attached - nice tuning - was just fine. The TCXO is putting out 740mV peak to peak of 40MHz according to my cheap scope.
I tried my Lime mini in both modes on S2 2/3 FEC and in USB2 too - no signal with green flashing light during Tx. Lime reports were all passed. Portsdown is on the 202101090 software.
I wonder what to do next?
Regards
David M0YDH

I've got the same problem David.

Langstone works OK, but cannot get a signal out of the Pluto with DATV. Oddly, when I go to the 'Output to' selection, the Pluto is greyed out and not surprisingly it does not go green if touched. However, when the main Menu 1 comes back up it shows that the Pluto has been selected!

From the ''Info' screen:
Like you I have the latest Portsdown software Buster 202101310.
Pluto is tweaked for extended frequency range, both cores enabled and has the August 2020 F5OEO firmware installed.
IP address is 192.168.1.104 (network) and 192.168.2.10 (Pluto)
Output to is Pluto

In Pluto Config:
Check extended range reports 'expanded to AD9364 status'
Pluto IP is set to 192.168.2.1
Pluto reboot causes both blue LEDs on the Pluto to dim but the reconnection times out.

The 40MHz clock oscillator is the original one.

The Pluto transmits DATV fine from my Win 10 PC running OBS with the RTMP streaming output targeting 192.168.2.1 as per Evariste's instructions.

73 Clive, G3GJA

Thanks Clive

I have an idea of what the problem might be. Portsdown addresses the Pluto as pluto.local rather than by its IP address.

The grey-out of the selection button is based on a response to the ping of pluto.local. Grey-outs are indications that something is unavailable, rather than "this button cannot be selected".

Please could you log in to your Portsdown by ssh, and then Ctrl-c to exit

Then and ctrl -c to exit.

I suspect the second ping will fail.

If so, it would be helpful if you could find out the network name of your pluto.

73

Dave

Hi Dave

Thanks for the reply.

So that I can find the right Pi amongst five on my network after doing a new build, I temporarily add "ip=192.168.1.104::192.168.1.254:255.255.255.0:rpi:eth0:off" in the same line in cmdline.txt in the boot folder. It forces the Ethernet interface to become dual homed, adding a fixed IP to the DHCP router assigned address. This avoids having to use the Angry IP scanner and work out which of half a dozen Raspberries on your network is the one you want.

Having got the P4 running, I hadn't removed the temporary addition to cmdline.txt, so to eliminate the possibility of a self-inflicted error, I removed it and then used the the correct method to create a static IP which modifies /etc/dhcpcd.conf. Testing again with the Pluto made no difference.

I then ran traceroute pluto.local and it correctly reported 192.168.2.1, although it took a long time for the DNS lookup to complete

I then ran pings to the IP and name and got this, again after a wait of more than 10 seconds:


That would suggest to me that the Name Service is working as it should.
Can you offer some further suggestions?

73, Clive

Thanks Clive

I am now very puzzled, because if you can ping pluto.local, the Pluto button on the "Output to" menu should not be greyed out (you can only see this if you select BATC or another output).

Can you successfully reboot the Pluto now that you can ping it? If, so, after a successful reboot, it might be worth trying TX again.

Dave

I've run up the Langstone again to make sure all is OK. No problems.

I then did a full power off reboot, including removing the power USB micro on the Pluto.

Reconnected USB power, switched P4 on and checked 'output to'. Still greyed out.

Ran Pluto reboot from M3 and Ready blue LED goes out and usually flashing blue LED1 goes dim at 27 secs.

Ready LED lights at 23 secs followed by LED1 flashing at 21 secs.

Countdown continues until counter reaches zero and then 'Failed to Reconnect to Pluto' is displayed.

Clive

A slow name lookup could be causing the problem. The name lookup on a stand alone Pi is quite quick, if it is taking a long time then it may be something else on your network is causing problems. Have you tried running Portsdown with the network unplugged?

Langstone also uses pluto.local but only the first time it talks to the Pluto. It then keeps the connection open so it doesn’t need to repeatedly re-establish the connection. I found this speeded up the Pluto access by a factor of about 20. It also fixed someone else’s problem where Langstone wouldn’t work if the network cable was connected.

I am not sure if Dave’s Portsdown code can be made to use the IP address instead of Pluto.local, if so then that would eliminate a name lookup problem.


Colin.

One other thing you could try would be to add
192.168.2.1 pluto.local
to the pi’s /etc/hosts file.
That should speed up the name lookup.