PE43703 Attenuator & Lime o/p Issues

[G8PEF]

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?
....

Mike

It might be significant, Mike. In my (admittedly limited) experience of making thinks talk to each other over SPI/IIC (mainly in the Arduino sphere) mixing 3.3V and 5V systems without level shifting can be problematic. I've sometimes had it work, but on other occasions I've seen problems ranging from 'doesn't work', through 'works when the wind is in the right direction', to 'oh, bugger, I never knew you could cram so much smoke into such a small device'...
I'd give it a try with the DSA running on 3.3V before getting too deep into code and such.

John
G8PEF

[G8GKQ]

Hi Mike and John

I've just checked, and the attenuator works with the latest Portsdown build (201912100). It changes on any band selection, or can be changed from the signal generator application.

The supply voltage for the attenuator should be 5.0v (mine is). There is no problem with driving it with a 3v3 logic signal. The spec https://www.psemi.com/pdf/datasheets/pe43703ds.pdf states that the high logic level simply needs to be above 2.6v, and the RPi achieves close to 3.3v. Clearly, if the attenuator was sending any data to the RPi, things would be very different (magic smoke...).

So, sounds like a problem with that specific attenuator. However, if it works for parallel control, don't throw it away. I have just made a parallel controlled drive attenuator for my QO-100 system - very useful.

Dave, G8GKQ

[G0LJF]

Hi John and Dave,

Thanks for the replies and advice.

I just checked the DSA on 3V3 and the fault still exists.
I must be faulty, but only in Serial mode.

Yes, I will be keeping it as it only cost £15 and operates from 9 KHz to 6 GHz. Worth every penny, even for Parallel mode only. I too have a PA for 2.4 GHz that needs careful control to avoid too much RF.

There is now another part on order from China.

I will let you all know what happens when that arrives.

Thanks, 73,

Mike

[G8PEF]

Thanks for confirming that the 5V supply to the DSA is ok, Dave - I had seen the data sheet figure of 2.6V for the 'logic high' on the PE device, BTW, but thought it worth mentioning the twitchiness I've experienced - and yes, the smokier incidents were when driving 5V levels into 3V3 devices - although I have had problems with intermittent/erratic operation the other way around with Arduino devices.

John
G8PEF

[G0LJF]

Hello again Dave,

Still here! Hope you all had a good XM/NY break.

I received my replacement PE43703 today (very good service, considering the distance, if you pay a little more for Air Mail).
I tested this in both Parallel and Serial mode before deploying to P2019 and it worked.

I have a piece of Windows stand alone SW that you can test PE attenuators with now, but you will need a Velleman K8055 interface board. If anyone wants a copy, let me know.

Anyhow, the P2019 now seems to set the attenuation correctly.

Initially, the replacement attenuator was not attenuating at all. I set some other values and rebooted and it now seems to be OK. I will report any further strangeness.

One serious thing I have seen since this P2019 was originally built, a month ago, is the random, complete drop-out of Tx power, just for about 1/4 second.
This can occur at any time and then it immediately recovers.

I suspect it is poor USB comms. It seems to be just about possible to reproduce if I fiddle with the USB plug into the hub but I am not convinced. It does not seem to be confined to one cable alone. Is it poor cable quality?

Dave, please, do you have any advice? I am going to remove the USB plug/socket from the cable/Hub and hard wire the thing, unless you disagree? And the Hub power (mains 5V PSU as supplied with the NewLink USB2 Hub).

Thanks,

73,

Mike

[G8GKQ]

Mike

Pleased that you have sorted the attenuator problem.

The short signal dropouts happen with the LimeSDR and sources other than the RPi Camera. It's a buffering problem in the encoder software. I am working on a cure for this, but a guide as to what works and what doesn't is here: viewtopic.php?f=103&t=6070#p19583

Dave

[G0LJF]

OK, Ta.

Let me repeat my experiment with the RPi camera. I was using the test card for my source.
Does the problem also occur with the supplied, recommended, video capture dongle?

You could try some nice debug messages with a timestamp on them - then you can get an idea of when the data arrives and when is it actually processed. That is the kind of thing I would try.

Thanks again,

73,

Mike