Next problem now the Pluto

[OZ7TA]

Hi all,

Back to the original reason reloading the SW from scratch.

After having worked very stable for a long time, the Pluto (version B) started a strange behaviour.

Using a spectrum analyzer I measure the signal coming from the Pluto's TX terminal.In SSB mode without modulation, the Pluto emits a very strong carrier, only 14 dB below the peak power. Modulation the signal with an audio generator, the emitted signal is in fact a sort of an AM signal with full carrier but only one sideband, and it is easily receivable on an AM receiver. In CW the Pluto also emits this signal constantly. This happens on all frequencies and also with both original FW (Version 35 or 38) and with F5OEO FW version 0303. The spectrum shown on the Langstone display is of course not showing the phenomonon. It can only be seen using a spectrum analyzer.

Looking at the TX signal during the Pluto's starting up, I do not see any sign of the famous Pluto calibration pulse, nor any sign of calibrating pulse after change of frequency.

I believe it is a HW problem in the Pluto or the associated OCXO or maybe some bad tables in the Pluto SW, but can anybody give a clue to what is going on?

Vy 73

Jorgen, OZ7TA

[radiogareth]

One of my pluto's sometimes has an upset, usually not emitting what you expect although all seems well with the LEDs, driver software/PD4.
I then check it with Satsagen software, running the Spectrum Analyser w/Tracking facility over the full range. If it has become corrupted in some way, the trace produces something that looks like a random square wave than is different every scan you run.
The cure is a full DFU reset and then install of the upgrades to full range, both CPUs and then your chosen firmware.
The details are on the wiki somewhere, I have to look them up every time it happens, but it brings it back to life and normal behaviour. I don't know what causes it.
Hope that helps...
Gareth

[OZ7TA]

Gareth,

Thank you for the hint for DFU. I had completely forgotten about that. I found a "DFU for dummies" at this website, DFU'ed the Pluto yesterday and all worked last night. But this morning I am back to "Square one", i.e. almost full carrier in SSB. Only change from yesterday is removing a jumper cable between the Pluto and the OCXO. Now I suspect the USB cable betwwe Pluto and the Raspi to be at fault and cause some sort of brown-out.

To be continued.

Vy 73

Jorge

[radiogareth]

Jorge, It might be related to the voltage supplied to the pluto. As you probably know, Raspberry Pis like 5.2 volts but the Pluto does not. The fix is to put a 1 amp Schottky diode (almost any sort will do) in the positive Wire to the Pluto - cut open the USB lead and fit it in the positive wire, repair/replace the insulation and it should still work. The Pluto gets about 4.8V and seems very happy at that level. Don't think I have had to DFU it since I made the mod. It will still work fine on your PC too, which should be at or very near 5.0V on the USB.
Worth a try before you buy a new lead.
Gareth

[OZ7TA]

Gareth and others,

I made som more tets this morning.

I have 2 Plutos:
Pluto ver. B assigned to my portable Langstone set-up. This one is running ADI FW ver. 38 and has been DFU'ed Tuesday.
Pluto ver. D assigned to my fixed QO-100 set-up. This one is running F5OEO ver. 0303 due to I am also doing DATV on QO-100.

Both Plutos are clocked form identical 38.88 MHz OCXOs. The OCXO level at the input of AD 93XX is 900 mVpp.

When running Langstone with the "B" the carrier suppression and supression of the unwanted sideband is only 30 dB. This is not a proper SSB signal (emission type J3E), but a reduced carrier signal (R3E) giving splatter in the adjacent channels.
By swapping the Plutos and running Langstone with the "D", the supressions are much better, at least 56 dB.
Doing the same excersise using SDR Console the result is the same: Good supression of carrier and unwanted sideband with the "D" but not with the "B".
I have also tried replace the OCXO on the "B" with an other OCXO, same result.

My conclusion is that there is a fault of a kind in the "B" and the good question is: What the H... is going on in that Pluto B?

Vy 73

Jorgen

[g4eml]

The carrier and opposite sideband suppression is dependent on the balance of the IQ mixer in the pluto. It sounds as if one of your Plutos has poor IQ balance.

The ADI documentation says that the balance is calibrated automatically whenever the Pluto frequency changes by more than 100 MHz. However it is a very vague about the details and in my development of Langstone I have never actually seen this recalibration happening. There also doesn't seem to be a way of manually triggering it.

You may have already tried it but if not then changing the frequency by more than 100MHz should cause a recalibration.

There are also some comments online saying that the balance is affected by the TX attenuator setting.

Colin G4EML

[OZ7TA]

Colin,

Thank you for response.

First: I forgot to answer Garerth's question about the suply voltages: Pluto B supply voltage is 4.9 V and Raspi4 supply voltage is 5.1 V, so that should be OK.

I have read about this calibration and I have seem some odd pulses being emitted, when the Pluto is powred up, but someties it powers up without those pulses (or maybe I am looking at the wrong frequencies). I have tried to change from 144 MHz to 1296 MHz, but have not seen any calbration either. However I will look into it once more later today and also try changing the TX attenuator setting.

Vy 73

Jorgen

[OZ7TA]

Hi,

It was a busy weekend, so the Pluto was postpned until yesterday evening.
All tests in the following are performed with Pluto powered at both USB connectors. The voltage measured at the Pluto board is 4.9 V.
All tests are performed in mode USB or FM with MIC Gain at 2, and TX ATT at 0 dB.

Most af the time Pluto emits some pulses when keyed first time after a change of frequency band, e.g from 144 to 432 or reverse. I guess this is the automatic calibration.
When changing from 70 to 144 or reverse, no pulses are emitted. Consistent with no calibration, if frequency change is less than 100 MHz.
In a number of band changes from 144 to 432 or 1296, NO pulses are emitted.
If calibration is performed, the calibration sometimes results in a carrier supression of only 8-10 dB. This happens in arounbd 40 % of all calibrations. One can the change band, key the transmitter on the new band and go back to the former band and key forcing the Pluto to do a new calibration, and suddenly the carrier supression is good.

The carrier supression varies between 22 dB and 40 dB relative to peak power. Best at 432 and 1296, worst at 70, 144 and 2400.
The unwanted sideband supression varies between 20 dB and 36 dB. Again best at 432 and 1296.
Reducing the TX output by 10 or 12 gave no improvement of the supression.

So there are three cases:
Calibration is performed resulting in a sort of carrier suptression
Calibration goes wrong resulting in almost no carrier supression
No calibration, where there should be a calibration

To be continued

vy 73

Jorgen, OZ7TA

[g4eml]

Jorgen,

That is interesting. As I said before, all of the calibration is handled internally and unfortunately the documentation I have found doesn't describe it in any detail.
It also sounds as if the variation between different devices can be quite large.

I wonder if what is connected to the RF ports of the chip makes any difference to the calibration success or fail.

If you do mange to find a method that works reliably then it should be possible to include it in the Langstone code.

73
Colin G4EML

[OZ7TA]

Colin,

It is a while since I last worked on the problem. The grass is growing and so do the weed and the RC flying season has also started.

As you suggested the level of residual carrier/unwanted sideband is strongly dependant of the attnuator setting. However one can only achieve between 39 dB and 11 dB supression strongly depending on frequency and attenuator setting. Best attenuation is at 5 to 15 dB TX attenuation.

I made the tests using a homemade simple GNU Radio script. Each time I ran the script the Pluto emitted a lot af calibration(?) pulses for around 6 seconds and after that a residual carrier was present at the TX port with about the same levels as in Langstone. I used the standard GNU Radio Pluto sink. The Soapy Sink would not run on the Raspi. By "keying" the TX, i.e. by sending data to the sink from a modulator, the residual carrier persisted and in SSB the unwanted sideband showed up, just as it did in the Langstone.

After having tried once more DFUing the Pluto and a roll bact to FW 0.32 with no success, I decided to purchase a new Pluto to get my
Langstone operational.

The Pluto B is now relegated to my ongoing project of writing an FM repeater in GNU Radio, primarily for local use in the 23 cm band. Here I can better manage the residual carrier.

So the problem is solved with respect to Langstone but it persists in the said Pluto and I have no clue why. I do not think it is an issue with the loads on the Pluto or the circuits between the chip and the TX connector.

I will close the thread for now. Thank you for participating to all. If something new pops up I may come back.

vy 73

Jorgen, OZ7TA