1) Connecting power measuring equipment to the output of the Lime mini with its gain set to 88 often the first few times I ask it to transmit I only get -40dBm of power then eventually it rises to around 0dBm where it should be. Then randomly it will drop to -40dBm even though no parameters have changed.
2) Accepting the above is unstable makes the second issue hard to debug but I am sure the PE43703 attenuator is simply not accepting commands from the Pi to reduce the power levels it stubbornly sits at 0.25dB loss. I have added the wiring of the Pi to the PE43703 which for clarity is using a Willow GPIO board where:-
PE43703 Wire Colour Willow board GPIO Pin on 40 pin header
DATA Yellow 6 31
CLK White 5 29
LE Grey 15 10
GND Black GND
The leads between Pi and PE43703 for LE, CLK and DATA have a 1k ohm series resistor in them to prevent damage to the Pi. I am not 100% confident that this how this should be done but cannot see how else it would work with a resistor.
The PE43703 has been modified as per BATC instructions to switch it to series mode. The LED illuminates on power up and pads that were altered have been checked for continuity as expected. DIP switches 1&2 have been set to off and on and they seem to make no difference.
Can anybody shed some light on these issues please - I have been stuck on this problems for weeks and am at loss to what to do.
Thanks Paul G6MNJ
- 2019-09-08 13.32.40.jpg (744.61 KiB) Viewed 1445 times
Issue 1: What video settings are you using? Please try Pi Camera 333KS FEC 7/8 DVB-S2. Alternatively try EasyCap (video in) 500 KS FEC 1/2 DVB-S.
Issue 2: All looks good to me. I have sent you a PM.
I recommend to double check that the Data, Clock and LE lines go to the correct functions on the Pi header. I initially had a similar problem with my attenuator board due to the Clock and Data lines being transposed.
Due to a self inflicted touch screen issue, I’ve been using Ethernet to control the Portsdown remotely.
My Lime Mini goes into a PE43703 enumerator being controlled from the Pi, and even though I’ve changed the attn level for the 2m band I was using, via the remote console, the signal level even after a reboot did not change.
I suspected it was the PE43703 or either my conf or my wiring, but after some investigation I found that if I disconnected the PE43703 interface and rebooted, I had about 32dB of attenuation, which is as it should be, however if I reconnected the interface and rebooted, I got about 5dB of attenuation, however I had configure Portsdown for 30dB of attenuation. To me this is saying that via the remote console, if you change the attn level, that change is not being passed on to the PE43703.
I have a brand new build P2019. I am using all standard or recommended parts from BATC shop. I am doing nothing which may be considered as "non standard". I am following all the BATC Wiki advice.
The software version was updated to Stretch 2019 12 100 on-line, but the original software was supplied by Dave C (BATC shop) on an approved (Dave C) SD card. A month or two back.
My set-up is completely standard and is Lime Mini (USB) based with 8 way outputs. I use an official RPi Model 3B+ with the official RPi mains (5.1V 2.5A) PSU.
I use the Farnell 7 inch touch screen and the official RPi Camera (Farnell).
I do not use the ADF synthesizer board (the Portsdown 2018 configuration). I use a externally (mains 5V PSU) powered USB 2.0 HUB to connect the Lime to the RPi.
I also use the BATC shop supplied "Video DVR" capture USB stick with the powered USB 2.0 Hub.
I use a Chinese PE43703 Digital Step Attenuator (DSA).Attenuator. This HAS been modified (and tested) as per BATC Wiki to only operate in Serial Mode. I have included 1K resistors in each of the three serial data lines (Data, CLK, LE). This runs on the RPi +5V supply.
The following are NOT used:
1) 4-Band RF Output Switch
2) 4-Band Decode Switch
3) 2-Way RF Switch
4) IQ Filter and Modulator Board
5) Synthesized Local Oscillator Source - not required for LimeSDR Mini
6) Local Oscillator Filters - not required for LimeSDR Mini
7) USB Audio (for now).
Whatever I do on Tx (and I have tried everything I can think of) the DSA never applies any attenuation. The output RF is always at the output level of the Lime SDR (less a bit I suppose, but who cares about a dB or two). I have set the attenuation to -16 dB (and other values, but this is the example I am quoting here).
I had to resort to my oscilloscope to find the cause.
Now the fault is with the Software. Whenever I press the Tx button (and on the subsequent Tx stop), the RPi sends the following 32 bits of data (in numeric nibble form; the reverse of the order actually sent) to the DSA/ADF which sets it to 0 dB attenuation (I believe in error).
44 00 00 00 Hex.
See file TEK_16TxOn
Here you can see a zero byte attenuation message sent to address 0. And also another zero byte message to what appears to be address 44h.
There is some hope, however. On a reboot the DSA is sent the correct attenuation binary pattern (for 16dB) but this is never sent ever again, and so the Tx button always sets the DSA to 0dB. Incorrectly.
See file TEK_16Boot
Here the value 00 42 Hex is sent (correct, 16 X 4, plus rounding error).
So the software has the capability to originally set the DSA attenuation but only one time on a boot.
I think that the software is still sending 32 bits of the serial data to the non existent ADF synthesiser (and an attenuator?) despite being configured to use Lime Mini. I believe this to be the nub of the problem.
You don't say what happens to the attenuator's LE line during these data exchanges. The ADF4351 VCO data might still be sent and its LE line enabled (pin 27), but the LE line to the attenuator (GPIO pin 10) is not enabled during that data. The attenuator LE line is only enabled when attenuator data is being sent.
Please could you take a look at that line and see if it goes to "enable" during band changes?
Thanks for the reply.
Yes, I checked the DSA serial messages are being sent on a band change.
They look OK to me. The LE is set at the end of the data.
I know that the DSA has a high attenuation of I disconnect all the serial lines from the Portdown and then reboot the Portsdown, I get no RF output at all.
So the Portsdown is sending/doing SOMETHING to make the DSA have 0 dB attenuation. For sure. It may be the LE pin on its own? Don't know?
I tried setting the manual DSA attenuation switches and again that made no difference.
Anyhow, I have removed the 1K resistors and still no improvement.
I have also traced the DSA pins right back to the IC and that looks OK to me.
So I am completely lost now.
I just bought the DSA and then used it. I never thought to test it first. I did test all my own board construction as I went, and they were OK.
I have a RF generator and a RF detector.
Is there a very simple DSA test program I can run on RPi? Without that I can only conclude that the DSA is faulty or I am still missing something? Probably obvious, too.
I found out that the PE SDA switches to 0 dB attenuation when both the CLK and DATA lines are at +5V, and then the LE (was at 0V) is taken to +5V.
I have no idea if that helps anyone, but there you are. This happens at the preliminary stages of P2019 booting (the rainbow screen).
As for the SDA, I reverted it to parallel mode and that works fine!
Something odd going on? Still persevering...
If you use the Portsdown Signal Generator, you can easily send the attenuator commands by changing the requested output level.
If you log in by ssh, and then restyart the touchscreen (type gui from the command prompt), you should see attenuator debug messages amongst the others on the screen.
I will try to connect my attenuator to one of my Portsdowns tomorrow just to check that it still functions in the latest version.
I will try your debug suggestions above. Thanks. Saves me writing some code.
The one thing that is still nagging me is the DSA supply voltage.
I am running my DSA from +5V, yet this model can operate on either 3V3 or 5V.
The RPi CPU (outwardly) operates at 3V3. Is this acceptable?
Could this be it? It is that simple?
In the meantime, I have ordered another duplicate DSA board from China.
They are cheap enough. I wont be doing that with the Lime SDRs!