ADALM-PLUTO SDR

[G0MJW]

These have started shipping. I ordered mine so long ago I had forgotten until UPS arrived with a parcel. They cost $99 and are based on the AD9369. They are intended as and are nice learning devices that run off a USB port. Frequency coverage is supposed to be 325MHz to 3.8GHz at 20MS 12 bit but those of us who have them have had success from 70MHz to 6 GHz after changing some of the parameters.

Has anyone else been looking at these and done any measurements? Naturally, the first thing I did was to take it apart and take some pictures.

Mike

[hendorog]

Very interesting that they can go from 70-6GHz. I thought the chip AD9363 was 325MHz to 3.8GHz.

Can to explain how you managed that one? It's definitely worth getting one of these if it can still be made to do that.

[G0MJW]

See this tweet from Alexandru Csete https://twitter.com/csete/status/897872430236094464 which pointed me at this post https://wiki.analog.com/university/tools/pluto/users/customizing which shouldn't work but of course we all immediately tried it.

Quote:

There were some early PlutoSDR devices which use the AD9364, which is nearly identical to the AD9363 used the production builds. If you have one of the AD9364 based PlutoSDR devices, it's a quick matter of using the U-Boot's fw_printenv and fw_setenv commands to get that device's larger tuning range (70-6000 MHz) and larger bandwidth (56MHz).

From your favorite serial application, just open a serial connection to the PlutoSDR. The username is root and the password is analog.

This will be the default (based on the AD9363):

# fw_printenv attr_name
## Error: "attr_name" not defined
# fw_printenv attr_val
## Error: "attr_val" not defined
#

To change things to the AD9364 configuration:

# fw_setenv attr_name compatible
# fw_setenv attr_val “ad9364”
# pluto_reboot reset

Unquote.

And there it was. I didn't have one of the AD9364 units, at least, that's not what it says on the chips, but it now seems to cover the wider frequency range. Perhaps the spec is not as good, or maybe there are holes in coverage, or maybe the AD9363 is a AD9364 that just didn't quite meet spec, or perhaps AD just want to be nice to us knowing in the long run it will help sales.

Mike

[hendorog]

Thanks, it seems certainly worth a try. I just ordered one from Digikey - NZD $148 which is about USD 108 at the moment.

Its worth noting that the AD9363 and AD9364 chips are $198  and $312 NZD on Digikey respectively so the PLUTO module is a great deal - even if the hack doesn't work!

[borjam]

I just ordered one

And nice anchovies!

[CopperCone]

Does this work with any popular software?

What is the probability of intercept on signals? I can't seem to find a spec sheet.

[hendorog]

Yes:
MATLAB®, Simulink® support
GNU Radio sink and source blocks
libiio, a C, C++, C#, and Python API

http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html#eb-overview

[hendorog]

Hmm, this recent comment implies the hack no longer works:

http://www.rtl-sdr.com/adalm-pluto-sdr-hack-tune-70-mhz-to-6-ghz-and-gqrx-install/
"I bought two of these from Digikey and I have carried out the AD9364 ‘hack’ on both units. GQRX refuses to tune below 324.999 and the GNURadio source and sink don’t work either. The units remain tuned to the last good freq. Pity because I was keen to try it on 2m."

I would not be surprised if some early chips were just 9364's in disguise and the later ones which are coming through now have been 'refined' to remove that capability.

[CopperCone]

Do you think it was 'refined' to restrict the capabilities from a 'military' or 'business is war' prospective, or if some engineer simply wanted to reduce error ? (i.e. advanced analysis revealed that there is some kind of measurement error with the 'hack' that voided specifications?

It's not like AD is a test equipment manufacturer, they have a vested interest in selling as much as those modules as possible.

https://finance.yahoo.com/quote/ADI/

[hendorog]

Do you think it was 'refined' to restrict the capabilities from a 'military' or 'business is war' prospective, or if some engineer simply wanted to reduce error ? (i.e. advanced analysis revealed that there is some kind of measurement error with the 'hack' that voided specifications?

It's not like AD is a test equipment manufacturer, they have a vested interest in selling as much as those modules as possible.

https://finance.yahoo.com/quote/ADI/

Of course not - and this is complete speculation on my part of course based on a single comment on a forum of someone saying it doesn't work for them...

I just think they always intended to remove the AD9364 functionality from the AD9363 chip once production ramped up. They could get 2 SKU's to market for the price of one and then refined the 9363 to match its specs.

[CopperCone]

hmm, do you think you can replace the chip?

seems unlikely that the code would 'ask' the chip but you never know

[hendorog]

hmm, do you think you can replace the chip?

seems unlikely that the code would 'ask' the chip but you never know

I'm guessing yes as the pinout is almost identical. But the price of the chip is so high I wouldn't bother.

Will wait and see what happens when it arrives.

[CopperCone]

Based on that post, it seems that whatever command is used to reconfigure the device was blocked...  though there is some contention on the website if its not just user error in doing the 'hack'

Or does it perform some kind of self test to see if the span settings are reasonable? Perhaps if you run the transmitter without a load there is crosstalk specification between TX and RX that is guaranteed by design as a self check.

I assume that " but it’s not guaranteed to give the full tuning range and bandwidth for every single unit." means that there is weird behavior, not software detected lockouts..

[borjam]

Curiously, the possibility of expanding the frequency range is mentioned on the Mathworks website.

https://es.mathworks.com/hardware-support/adalm-pluto-radio.html

[CopperCone]

does anyone know what USB speed this device uses?

[RoGeorge]

USB 2.0
https://wiki.analog.com/university/tools/pluto/users/name?rev=1487174293

[hendorog]

Mine has just arrived from Digikey. Need to download stuff I assume and will post an update once I've had a crack at the hack.

[borjam]

Mine has just arrived from Farnell. Seems to be out of stock everywhere.

So far I am looking at documentation and checking what I need in order to install GnuRadio on Mac OS X properly.

For now I have plugged it, updated firmware to the latest version (0.22) and tried two hacks. Enabling the AD9364 hack
in order to increase the tuning range, and something else I found on plutosdr.com: enabling a second CPU core.

dmesg shows this after doing the AD9364 hack:

Code: [Select]

cf_axi_adc 79020000.cf-ad9361-lpc: ADI AIM (10.00.b) at 0x79020000 mapped to 0xe0938000, probed ADC AD9364 as MASTER

Not sure wether it really detected an AD9364 or it just assumes it thanks to the fw environment variables I set.

As for the dual core hack shown here: https://www.plutosdr.com/viewtopic.php?f=7&t=11

It worked for me:

Code: [Select]

# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 666.66
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

processor : 1
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 666.66
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Xilinx Zynq Platform
Revision : 0003
Serial : 0000000000000000

So much to explore so far, for now I have just done blind "script kiddying"

[hendorog]

Bit of an update from me:- it does seem to tune ok after the hack. I could see the FM BCB on the waterfall.

A few tips and references:

The easiest way to do an initial test and get it to do something  is to install the windows IIO oscilloscope app.
https://wiki.analog.com/resources/tools-software/linux-software/iio_oscilloscope

The easiest path by far to get GNU Radio going with the drivers is to use a linux box. Virtual box is fine.

Disk images for virtualbox and vmware can be downloaded from here:
http://www.osboxes.org/ubuntu/

Edit: I'm using Ubuntu 16.10 for the following. I've tried 17.10 but found the gnu-radio compile fails.
There is an alternative approach here for 17.04 and newer: https://wiki.analog.com/resources/tools-software/linux-software/gnuradio

Once linux is up:
Install pip:

Code: [Select]

sudo apt-get install python-pip

Use pybomb to install gnu radio - instructions came from here: https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why/

Code: [Select]

sudo pip install pybombs
pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git
mkdir prefix/
pybombs prefix init -a default prefix/default/ -R gnuradio-default

Edit the gr-iio pybomb recipe to install the latest code instead of a tag - instructions came from here https://www.reddit.com/r/RTLSDR/comments/6tnjba/getting_started_with_adalmpluto_and_gnu_radio/

Code: [Select]

sed -i 's/gitrev.*/gitbranch: master/' ~/.pybombs/recipes/gr-recipes/gr-iio.lwr

Now use pybomb to install gr-iio

Code: [Select]

pybombs install gr-iio

Run Gnu Radio

Code: [Select]

source ~/prefix/default/setup_env.sh
gnuradio-companion

Load and run the attached gnuradio sample file

Note the source URL which worked for me: ip:192.168.2.1
The one in the docs didn't work (ip:pluto.local) - perhaps I missed something.

[RoGeorge]

As found on Internet, one of the ADALM-PLUTO designers talks about the board using a custom Zynq 7010, with only one core. Maybe they switched to the usual 2 core Zynq now.

Regarding the other hack, for the frequency range, reporting the chip as being an AD9364 is one thing, but it is not clear enough for me, because I don't have a board:

Can you tune the Rx/Tx in the 70-6000 MHz range after applying the frequency hack, please?
Can you, let's say, receive an FM radio station after applying the frequency hack, or see the spectrum of a 5 GHz Wi-Fi router?

[hendorog]

As found on Internet, one of the ADALM-PLUTO designers talks about the board using a custom Zynq 7010, with only one core. Maybe they switched to the usual 2 core Zynq now.

Regarding the other hack, for the frequency range, reporting the chip as being an AD9364 is one thing, but it is not clear enough for me, because I don't have a board:

Can you tune the Rx/Tx in the 70-6000 MHz range after applying the frequency hack, please?
Can you, let's say, receive an FM radio station after applying the frequency hack, or see the spectrum of a 5 GHz Wi-Fi router?

Yes I read that single core comment too. However the thing definately has two cores, I've tried it and get same results as borjam.

I mentioned in my last comment that it tunes to the FM broadcast band, I guess you didn't read that bit - check out that attached image.

[CopperCone]

did you measure its probability of intercept?

I may do so today using my tektronics 284 picosecond pulser or my wavetek pulse generator.

I guess i hook it up to a counter and an antenna and see how many intercepts there is over a period of time for various wave periods , not sure of the proper procedure

then calculate it over a course of a few hours

[hendorog]

did you measure its probability of intercept?

I may do so today using my tektronics 284 picosecond pulser or my wavetek pulse generator.

I guess i hook it up to a counter and an antenna and see how many intercepts there is over a period of time for various wave periods , not sure of the proper procedure

then calculate it over a course of a few hours

Nope, and I don't know much about that apart from what I read about SignalHounds implementation.

I guess the USB 2 will be a limitation it so some sort of processing on the device would be required.

[G0MJW]

did you measure its probability of intercept?

I may do so today using my tektronics 284 picosecond pulser or my wavetek pulse generator.

I guess i hook it up to a counter and an antenna and see how many intercepts there is over a period of time for various wave periods , not sure of the proper procedure

then calculate it over a course of a few hours

Don't take this the wrong way but what are you talking about? And maybe also why is it important?

[CopperCone]

Ok, I repaired my pulse generator. I think I can determine probability of intercept by comparing my waterfall graph to a counter hooked up to a pulse generator with specific delay between short pulses.

Is there a way to some how 'count' the waterfall with GNU Radio?

[borjam]

Don't take this the wrong way but what are you talking about? And maybe also why is it important?

Suitability as a spectrum analyzer, for instance

[CopperCone]

For finding infrequent burst transmissions and transient events.


Lets say you key a transmitter for 4 microseconds. If you use a sweeping generator, that takes 10mS to perform the spectrum sweep, you have a rather low chance of hitting it. If you have something that takes 10 microseconds to do the same sweep, you have a fairly good chance of hitting it.

It's described mathematically as the chance you will see the full signal on your instrument. Similar to waveforms per second on an oscilloscope, so you can see glitches and shit.

[dcarr]

This is a device that continuously streams samples at fixed (maximum) rate.  If we can assume that it's not dropping samples which it shouldn't be, then the POI should be largely determined by math and the software.  That part will depend upon the width of FFT bins you choose, window function, overlap, signal duration, and how well centered your signal is in the bin(s).  If you're interested in the contribution from the noise, you should be able to figure that out from the combination of the device noise figure (see the front end datasheet) and the quantization noise.  If you do some googling, there are some good app notes out there on this topic.

Hope that helps,
David

[CopperCone]

How come on narrow bandwidths it looks like the pluto sdr noise floor has a 'bow' to it?

[G0MJW]

Amateurs in the UK have just discovered the LO harmonics mix with baseband and are providing usable test signals on 10 GHz - so that's another band to tick off. Sometimes spurious outputs can be useful, as long as filtered.

http://www.batc.org.uk/forum/viewtopic.php?t=5129&p=13565#p13565

Mike

[CD4007UB]

The Pluto RF output has quite strong harmonics. With Tx output attenuation of 10dB (in IIO Oscilloscope) at 500MHz, the low-order harmonics measured on a spectrum analyser are:

1st 500Mhz -1.8dBm
2nd 1GHz -51dBm
3rd 1.5GHz -11.2dBm
4th 2GHz -54dBm
5th 2.5GHz -18.6dBm

The strong odd and weak even harmonics suggest the waveform is approximately a square wave at this frequency. With a 1GHz fundamental, I find -16.3dB at 3GHz (so, a bit more sinusoidal).

[CopperCone]

I notice when I have a bicone hooked up to it, this happens

I am at center frequency 2GHz with a span of 1Ghz. I see a strong signal at 1600MHz.

I center it at 1500MHz with a bandwith of 500MHz, the 1600MHz signal goes away.

What is going on?>

[borjam]

I have successfully compiled iio-oscilloscope on Mac OS X. It was quite a nightmare but it seems to work

I'll reproduce it on a virgin machine and try to contribute a set of diffs to AD. It involved installing some dependencies using Macports (gtk, glib, etc), installing gcc (Clang won't accept the compiler flags used by AD) and editing several files mostly to fix paths to include files.

I have one question, however: does the spectrum analyzer tab actually work? No matter what I try I get this error:

Failed to set the rx sampling rate to 20.000000in configure_data_capture

(Ignore the "20" value, it was originally 61.44 MSPS but it doesn't work either.

I can confirm that the bandwidth hack worked on mine. This is a screenshot of the FM broadcast band.

[CopperCone]

I noticed something, its probably not too important due to the high frequencies used, but unlike most lab equipment, the plutosdr has a 1kohm resistance between ground and USB. (unlike most equipment that has bulkhead connectors, and is directly grounded to the chassis earth.

Also, with the hack, since sampling is increased, should any other parameters be varied to satisfy FFT equations and theorum? Like the sample size for a FFT? (since it goes from 20 to 60 megsamples).. I assume with the wrong settings its not exploiting the sample rate to the max.

[borjam]

I have noticed a lot of interference on my SDR_Pluto when I tune it to 430 MHz.

Is this normal? I have cross checked with another SDR (SDRPlay) and an AR8600 receiver and I don't see such interference here.

[CD4007UB]

I just checked my Pluto SDR with MATLAB at 433MHz with 60MHz sample rate and 70dB gain. The spectrum is clean, except for a small spur at 440MHz about 7dB above the noise. (That may be a harmonic from the 40MHz onboard crystal.) IIO Oscilloscope shows basically the same spectrum. The Rx input was terminated with 50 ohms.

[borjam]

Thanks. Silly me, must be interference from a nearby cell phone mast (there's one on my roof, another one 50 metres away).

I'll try at a different location.

[CopperCone]

I have a similar harmonic on mine, I read complaints about that frequency on the RTLSDR reddit forum, some people think it might be from USB (might be a common problem among cheap SDR). I see it at 460 MHz. with nothing plugged in.

My HP equipment does not show it, even with a large antenna, with a noise floor of -144dBm, i'm pretty sure its not cell phone or anything like that, since I have the units are physically very close together.

[SNGLinks]

A video of a talk at BATC's CAT17 Convention.

https://youtu.be/idW3ysqvMno

Edit
Sorry I can't seem to link to the start of the video. Please rewind to the start.

[davorin]

I know it's an old thread...but recently a new batch arrived at Digikey so I had to order one....Mouser postponed their shipping date from May 24th to now somewhere in July....

It still uses the AD9363 but it can't be tweaked for a wider range...I was able to receive FM broadcast with SDRAngel on Linux...
Also the Dual-Core hack works...as it uses the real Zynq 7010 dual-core device...

If you need one...hurry as Digikey has only 60 pieces left at the moment (o;

[tsman]

It still uses the AD9363 but it can't be tweaked for a wider range...I was able to receive FM broadcast with SDRAngel on Linux...

Huh? It can't be tweaked but you're receiving FM broadcast? AFAIK there is no change on the AD9363.

Also the Dual-Core hack works...as it uses the real Zynq 7010 dual-core device...

Yes. It is a real Zynq 7010 with two CPU cores but they're paying a lower price to Xilinx to only use a single core. The FPGA design doesn't fit in the cheapest single core 7007S and the next step would be the 7012S which is more expensive than the 7010.

The end user can enable both cores with no problems.

[davorin]

Yes...I was receiving FM broadcast last week after setting those u-boot bootloader parameters...dunno if it goes higher than 3.8GHz as my R&S generator only goes up to 3GHz (o;

I could test with the R&S with FM if it can go down to 70MHz....

Attached screenshot with FM broadcast receiving...

[Qw3rtzuiop]

AD published a nice book that is about SDRs featuring the Pluto. The pdf can be downloaded for free.

http://www.analog.com/en/education/education-library/software-defined-radio-for-engineers.html

[Geoff-AU]

3rd 1.5GHz -11.2dBm

ouch.  needs lots of filtering.

I notice when I have a bicone hooked up to it, this happens

I am at center frequency 2GHz with a span of 1Ghz. I see a strong signal at 1600MHz.

I center it at 1500MHz with a bandwith of 500MHz, the 1600MHz signal goes away.

What is going on?>

Aliasing.  It's a strong out of band signal at another frequency that's not being filtered out.  Often if you move the centre frequency slowly you can see an aliased image move in the opposite direction to all the other signals in the span.

[Taucher]

Just a small post regarding my experience regarding crashes and lockups with the ADALM-PLUTO board (Rev. B):

My Pluto board sometimes seemed to stall when connected to the antenna - SDR# also crashed when such a stall happened. Using an USB-ETH-Interface the situation did not change at all - the board would still stall from time to time.

Some measurements later the problem was narrowed down to electric pulses due to switching of lamps and (capacitor-based) motors.
Those devices caused a spike for in the coax-shield (approx 60V, 5-20µs duration, 1-2 MHz freq.). 
To check if the device was frozen or just the USB connection I decided to connect an CP2104-MINIEK serial adaptor to the internal RX/TX/GND and see if the device continues to run when the connection is lost.... but the problem was gone - no chance to reproduce it while the serial cable was fully attached.
Well, that was a start - and according to the Analog wiki there were reports for EMC problems with the USB-OTG-detection circuit... so I decided to check out the grounds. 

Diagnosed problem:
Power-GND and GND have a common mode choke as only connection, but that choke does more harm than good when there is a sudden rise in the GND "level".

Solution:
My fix for the situation was simple: I added a bypass/bridge that directly connects GND and Power-GND. In addition I also bridged the 1k resistors to the USB-shields, but I suppose that measure was unnecessary.

Attached you can find the schematic.

[blackbird]

I know it's an old thread...but recently a new batch arrived at Digikey so I had to order one....Mouser postponed their shipping date from May 24th to now somewhere in July....

This is odd, I ordered a Pluto last week at Mouser. Order placed Tuesday (12-6) and received the package two days later (14-6).

[RoGeorge]

Indeed, now there are plenty on stock at Mouser EU. Quite in sync with the new Analog Devices free book about SDR.

That made me ordered an ADALM-PLUTO last night.
Can hardly wait for it to arrive 

Thanks for both the link to the book and the news about the replenished stock.

[CopperCone]

Just a small post regarding my experience regarding crashes and lockups with the ADALM-PLUTO board (Rev. B):

My Pluto board sometimes seemed to stall when connected to the antenna - SDR# also crashed when such a stall happened. Using an USB-ETH-Interface the situation did not change at all - the board would still stall from time to time.

Some measurements later the problem was narrowed down to electric pulses due to switching of lamps and (capacitor-based) motors.
Those devices caused a spike for in the coax-shield (approx 60V, 5-20µs duration, 1-2 MHz freq.). 
To check if the device was frozen or just the USB connection I decided to connect an CP2104-MINIEK serial adaptor to the internal RX/TX/GND and see if the device continues to run when the connection is lost.... but the problem was gone - no chance to reproduce it while the serial cable was fully attached.
Well, that was a start - and according to the Analog wiki there were reports for EMC problems with the USB-OTG-detection circuit... so I decided to check out the grounds. 

Diagnosed problem:
Power-GND and GND have a common mode choke as only connection, but that choke does more harm than good when there is a sudden rise in the GND "level".

Solution:
My fix for the situation was simple: I added a bypass/bridge that directly connects GND and Power-GND. In addition I also bridged the 1k resistors to the USB-shields, but I suppose that measure was unnecessary.

Attached you can find the schematic.

I measured it before and I thought there was also a series resistor between the grounds ? IIRC my measurement was in the kiloohms.


BTW as a mod for my plutosdr, purely based on hunch, I wrapped the thing in two layers of copper tape and sandwiched the tape down to the star washer on the SMA connector. I made a cut away around the signal USB port to maintain their designed ground isolation but I was tempted to short it out to the shield. It seemed really dumb to have a plastic enclosure on a USB device that works to 6GHz.

I suspect that choke will improve things so long its not being overloaded or whatever is going on, I am sure AD put it there as a result of a measurement they are RF experts, but it is a bad design, and it does not sound like chassis shielding would help much?

Can you explain what the mechanism is behind the failure? Is the impedance of the ground plane not low enough relative to the power and signal planes, so a impulse on the shield/circuit ground causes a rise in the signal layer? Might it be better to completely float the USB shield and use isolation?

[Taucher]

I measured it before and I thought there was also a series resistor between the grounds ? IIRC my measurement was in the kiloohms.

BTW as a mod for my plutosdr, purely based on hunch, I wrapped the thing in two layers of copper tape and sandwiched the tape down to the star washer on the SMA connector. I made a cut away around the signal USB port to maintain their designed ground isolation but I was tempted to short it out to the shield. It seemed really dumb to have a plastic enclosure on a USB device that works to 6GHz.

I suspect that choke will improve things so long its not being overloaded or whatever is going on, I am sure AD put it there as a result of a measurement they are RF experts, but it is a bad design, and it does not sound like chassis shielding would help much?

Can you explain what the mechanism is behind the failure? Is the impedance of the ground plane not low enough relative to the power and signal planes, so a impulse on the shield/circuit ground causes a rise in the signal layer? Might it be better to completely float the USB shield and use isolation?

The problem is not that the Pluto is crashing - it's just that a sudden change in any GND causes an edge on the USB-OTG-detection (and that leads to an unwanted switchover between host-mode and client-mode for the USB port). Such a rise happens when connecting different GND potentials together (antenna to Pluto is one example) or when there is travelling disturbance in the incoming GND due to some household devices or nearby lightning.

Now any such disturbance would usually be a job for the choke ... and it would do a good job - but it is also an inductor ... and inductors cause a phase-delay ... on it's own that's not a problem, but the OTG-measurement-path is not choked and hence there is no phase-delay there.
Now feel free to guess what happens when you offset a 60V AC-spike by 90°

Quite possibly there are better solutions than mine (post them please  ). My guess would be some really strong low-pass filtering to the detection pin (but adding a C_filter next to an L_choke could cause some nasty byproducts as resonances and ringing... I didn't bother to try). The correct fix would probably be an additional choke which allows for (co-)choking of the OTG-sense, but adding such a part to an existing Pluto is nontrivial

The posted solution has been tested to work (I've also received feedback from one other person who had Pluto crashes as well - and not a single "crash" since the mod was applied). After all, risking some PowerGND-noise (haven't measured) is much less an issue than the whole system losing it's USB connectivity.  My Pluto shows superior performance compared to any other SDR in my posession, so I'm quite happy with it

Regarding R between grounds: please consult the schematic... my proposed fix creates a low impedance bypass so any existing parts between both grounds will continue to work in respect of the ratio created by the respective voltage-divider.. as a wire is nearly 0 ohms it becomes the strongly preferred path for the current (basically it gets all of it). In my device I also bridged some ground-separating R like R55 ... but that's not necessary and I was too lazy to undo it as it has it didn't affect my Plutos performance.

Regarding any added shielding: I experienced some RF-reflection problems - in my case I tried adding copper planes of single sided PCBs (cut to fit the enclosure) ... such shielding didn't help with the OTG-loss but caused the noise-level to worsen significantly - especially when the shield was close to the RF-input, chip and the chokes in between both. It's not necessarily bad to radiate some unwanted RF away - I didn't have RF-absorbant material around, but even then I'd expect bad HF voodoo to happen when adding anything with a dielectric constant near any RF part

PS: What also helped (a bit) was just creating a really good GND-connection (I used alligator-clips and lab cables) from the SMA port to my local grid's earth conductor - this reduced the GND-interference conducted by the coax-shield arriving at my pluto by providing an alternative path to earth. For obvious reasons this just helped with mild interference as it just weakened the incoming stray signals (at risk of ground-loops).
Choking with a clip-on ferrite didn't help as the frequency is quite low and the intensity too strong to simply choke away.

[CopperCone]

how did you ground the shield you made? I don't see any other method then binding it to the RF i/o if you want to not mod the chassis?

[mrf184]

re: tuning range, I bought some AD9363 chips ($10 each from shenzhen), made a quick test board with a Spartan-6 FPGA and USB interface, and wrote some code to configure it over USB using the AD no-OS API. The API does not ask the chip whether it's a 9363 or 9361, but rather you specify this in your code. I specified AD9361 and it tunes the full frequency range. Here it is picking up some FM broadcasts:

[RoGeorge]

That's a very interesting project (especially given the price for AD9363), I would like to see more. 

[xaxaxa]

bootleg plutosdr (collab with mrf184):


It can do up to 14MS/s through the usb 2 interface.

Will post schematics and layouts.

[Kalvin]

Got mine today from digikey. Tuning hack and dual-core hack work just fine. After tuning hack I can receive FM stations around 95 MHz using the Gqrx 2.11.5. Installing the GNU Radio package and building the GNU Radio blocks for Pluto on Linux Mint 18.3 was easy without any problems.

[xaxaxa]

Here are the schematics and PCB layout (gEDA) of the simple ad9363 SDR. There is one errata which is that the RESET pin of the ad9363 should be wired to a FPGA i/o pin.

EDIT: also added gschem symbol library

The ad9363 is connected to a spartan 6 FPGA (xc6slx9) which interfaces to USB using the usb3343 phy. Attached is a VHDL core that packs the 12-bit I/Q samples (24 bit words) into 3 bytes and sends an occasional sync word, plus a gnuradio plugin (in c++) that goes along with it. To configure the ad9363 currently the fpga logic accepts bitbanging commands via usb, and code is added to platform.c (in AD's no-OS library) to bitbang spi.

There are 4 RF channels routed, 2 tx and 2 rx. One tx/rx pair is connected to a 800/900MHz frontend (antenna switch + acpm-7868 PA), and the other tx/rx pair is broken out directly (the tx has a wideband trf37a75 gain block for higher output power up to 15dBm).

Total cost including PCB prototyping is less than a real plutosdr 

[Hagrid]

Hello, has anybody got an pluto SDR recently (a few weeks or days ago) and tested if it still can be unlocked to the full frequency span (70MHz to 6GHz)?
It would be nice if someone has made some tests over the whole range with newer units too.

[tsman]

Hello, has anybody got an pluto SDR recently (a few weeks or days ago) and tested if it still can be unlocked to the full frequency span (70MHz to 6GHz)?

Same revision PCB. Same revision Zynq and AD9364. You can still unlock the second ARM core in the Zynq and still expand the tuning range of the AD9364.

[OwO]

Anyone know if it's possible to add an SD card or some other way to expand storage on the plutoSDR? As it stands there's no way to install a real Linux system because the onboard flash is way too small. I want to run something proper like Debian so that development isn't a pain.

[Hagrid]

Hello, has anybody got an pluto SDR recently (a few weeks or days ago) and tested if it still can be unlocked to the full frequency span (70MHz to 6GHz)?

Same revision PCB. Same revision Zynq and AD9364. You can still unlock the second ARM core in the Zynq and still expand the tuning range of the AD9364.

Thanks a lot! Will order today, thats a really nice price for such a unit.

[tsman]

Anyone know if it's possible to add an SD card or some other way to expand storage on the plutoSDR?

If you have micro USB OTG adapter then you can attach USB devices. A USB 3 gigabit Ethernet adapter is recommended even though the ADALM-PLUTO is only USB 2 as 100BASE-T will be a bottleneck.

[wolfp]

I received PLUTO in July 2018 and expanded it to 70MHz - 6GHz. Then I made some measurements using a calibrated R&S Generator and a R&S (broadband) power measuring system.
Result: Output power 50MHz to 6GHz more then 0 dBm, max. 9dBm at 500MHz. The output is non-sinusodial therefore the result (measured broadband) is influenced by the waveform.

I tested the receive-path using a -20dBm  signal from 70MHz to 6GHz. Pluto showed abt. -30dBfS with a maximum of -24dBfs at 1500MHz (i have to look closer for the reason). The usable dynamic-range seems to be between -80dBm (-90dBm under 3GHz) and -10dBm.

All attenuators set to 0dB, using 0.1m RG174 SMA-SMA (comes with PLUTO) and N-SMA adapter.

Wolfgang

[ploegmma]

Just a small post regarding my experience regarding crashes and lockups with the ADALM-PLUTO board (Rev. B):

My Pluto board sometimes seemed to stall when connected to the antenna - SDR# also crashed when such a stall happened. Using an USB-ETH-Interface the situation did not change at all - the board would still stall from time to time.

Some measurements later the problem was narrowed down to electric pulses due to switching of lamps and (capacitor-based) motors.
Those devices caused a spike for in the coax-shield (approx 60V, 5-20µs duration, 1-2 MHz freq.). 
To check if the device was frozen or just the USB connection I decided to connect an CP2104-MINIEK serial adaptor to the internal RX/TX/GND and see if the device continues to run when the connection is lost.... but the problem was gone - no chance to reproduce it while the serial cable was fully attached.
Well, that was a start - and according to the Analog wiki there were reports for EMC problems with the USB-OTG-detection circuit... so I decided to check out the grounds. 

Diagnosed problem:
Power-GND and GND have a common mode choke as only connection, but that choke does more harm than good when there is a sudden rise in the GND "level".

Solution:
My fix for the situation was simple: I added a bypass/bridge that directly connects GND and Power-GND. In addition I also bridged the 1k resistors to the USB-shields, but I suppose that measure was unnecessary.

Attached you can find the schematic.

I'm glad I found this thread. I think I have the same issue. I'm using the Pluto with a network adapter over OTG and that seems to work great. The whole point of this was to get the Pluto off my desk and install it near my discone where I have UTP also. But then the problems started. It stopped working and I spent hours on searching for a cause (fiddling with the network, cable, switch, adapter, power, etc.). At a certain moment I dragged a long cable with me from my desk (where things worked) to the antenna location where it stopped working each time. Then (when it still stopped working at that location) I figured that the only difference was the antenna. I just had to contact the antanna ground to the Pluto (antenna input) ground for a while and the network activity LED on the network adapter stopped blinking!
To figure out the rest of the story was a bit outside my knowledge area. But when I read your post it all made sense... So of course I want to make this modification. Perhaps you could make a close-up photo of it (just to be sure). And did you use enameled wire? What gauge (if that matters)?

Thnx, Majodi

[ploegmma]

Regarding any added shielding: I experienced some RF-reflection problems - in my case I tried adding copper planes of single sided PCBs (cut to fit the enclosure) ... such shielding didn't help with the OTG-loss but caused the noise-level to worsen significantly - especially when the shield was close to the RF-input, chip and the chokes in between both. It's not necessarily bad to radiate some unwanted RF away - I didn't have RF-absorbant material around, but even then I'd expect bad HF voodoo to happen when adding anything with a dielectric constant near any RF part

PS: What also helped (a bit) was just creating a really good GND-connection (I used alligator-clips and lab cables) from the SMA port to my local grid's earth conductor - this reduced the GND-interference conducted by the coax-shield arriving at my pluto by providing an alternative path to earth. For obvious reasons this just helped with mild interference as it just weakened the incoming stray signals (at risk of ground-loops).
Choking with a clip-on ferrite didn't help as the frequency is quite low and the intensity too strong to simply choke away.

This I would like to test also. I made a shielded box to fit the Pluto, hoping it would create the best possible environment for it. Didn't think it could have a negative side to it. Where (frequency) and what exactly do you see with these RF reflections?

Majodi

[a59d1]

re: tuning range, I bought some AD9363 chips ($10 each from shenzhen), made a quick test board with a Spartan-6 FPGA and USB interface, and wrote some code to configure it over USB using the AD no-OS API. The API does not ask the chip whether it's a 9363 or 9361, but rather you specify this in your code. I specified AD9361 and it tunes the full frequency range. Here it is picking up some FM broadcasts:

where tf in shenzhen are you getting a $120 chip for $10?

[OwO]

https://item.taobao.com/item.htm?spm=a230r.1.14.59.48bc2db7Ybdwv7&id=576472782264&ns=1&abbucket=9#detail

https://item.taobao.com/item.htm?spm=a230r.1.14.17.48bc2db7Ybdwv7&id=539437082795&ns=1&abbucket=9#detail

[a59d1]

https://item.taobao.com/item.htm?spm=a230r.1.14.59.48bc2db7Ybdwv7&id=576472782264&ns=1&abbucket=9#detail

https://item.taobao.com/item.htm?spm=a230r.1.14.17.48bc2db7Ybdwv7&id=539437082795&ns=1&abbucket=9#detail

Wow. Surely these are factory rejects, right?

[radiolistener]

Wow. Surely these are factory rejects, right?

I think these are Chinese clones, they are not genuine

[OwO]

I think these are Chinese clones, they are not genuine

I would be impressed if the Chinese can actually clone a chip of this complexity.

There is a peculiarity with the taobao AD9363 which is they all have the BBCZ suffix while distributors all only stock the ABCZ suffix. Arrow lists AD9363BBCZ but without a price and not available for order. The datasheet also only lists ABCZ.

EDIT: https://ez.analog.com/wide-band-rf-transceivers/design-support/f/q-a/80027/what-is-difference-of-ad9363-abcz-and-bbcz

BBCZ is not an open market release part, Kindly request customer to contact ADI directly for such queries.

FYI.

AD9363ABCZ Band: 325 MHz to 3.8 GHz

AD9363BBCZ Band: 650 MHz to 2.7 GHz

These are the ones that went into DJI drones and now have hit the market.

[radiolistener]

I would be impressed if the Chinese can actually clone a chip of this complexity.

then, how they do it cheaper? Factory rejects?

[2N3055]

 
there is only AD9361BBCZ in AD datasheet....
https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf

[RoGeorge]

I don't think the AD9361 price is about chip complexity.

Saying that because, judging by the current selling price, it's hard to believe the AD chip is on par with, let's say, a CPU like AMD or Intel, which are about the same price, and running at about the same frequencies, yet the CPUs are way more complex and huge in area when compared with an AD9361.

[radiolistener]

the CPUs are way more complex and huge in area when compared with an AD9361.

the CPUs produced in large quantities, so their price is distributed over quantity.
But this is not the case for RF Transceiver chip.

[tsman]

https://zeptobars.com/en/read/AD9361-SDR-Analog-Devices-DAC-ADC-65nm

[vik007]

Hello Gentlemen,

A few days ago I bought an Adalm Pluto SDR, I did the first Test of reception and it works very well.

I tried to make a change after this tutorial:     I did not succeed, I probably did not do something right or it was not the software.

After this failed operation, plutoSDR does not do anything, no longer sees any COM port, the computer no longer recognizes it as a storage unit.

When connecting to USB sees only the Device Manager PlutoSDR DFU.   

Has anyone else happened to this wonderful little box?

Please help me,

Thank you  (Victor - yo3dex)

[mayor]

Hi,

hopefully, this article will be of help:

https://wiki.analog.com/university/tools/pluto/users/firmware#dfu_update

[vik007]

 thanks for the answer,

 I have not yet solved, I do not know how to organize those files. I still study, 

[mayor]

Hi. Your device is in DFU mode (which means it's wanting new firmware -- it's not bricked as far as I can tell)
So, per AD doc:

"When does the device automatically enter DFU mode?
The device enters DFU mode in case booting the multi component FIT image (Flattened Image Tree) fails. This may happen due to checksum failure caused by a corrupted previous firmware update."

"How can I check if the device is in DFU mode?
When the device is in DFU mode, the DONE LED is OFF, while LED1 is constantly ON. The device switches it’s USB PID to 0xB674 (PlutoSDR DFU)"

"How to update the firmware using DFU mode? How to rewrite the default uboot environment?" ->

Download this file:
https://raw.githubusercontent.com/analogdevicesinc/plutosdr_scripts/master/UPDATE.BAT

Then download the latest firmware:
https://github.com/analogdevicesinc/plutosdr-fw/releases/download/v0.30/plutosdr-fw-v0.30.zip

Unzip the firmware zip file in the same location

In a windows cmd prompt, go to the directory where you downloaded both files and type
UPDATE.BAT plutosdr-fw-v0.30/pluto.dfu

Wait a while as the update of the firmware happens.

Once done, disconnect from USB, then reconnect. Should be back to normal.

If that doesn't work and your device is still in DFU mode, you might want to try

UPDATE.BAT plutosdr-fw-v0.30/uboot-env.dfu

[wkb]

That is what I did and it works just fine.  Using my Pluto as trx for the Es'hail2 aka QO100 sat.

It sits close to the dish, remotely operated via Ethernet.

Wilko

[rfclown]

Old thread, but didn't want to start a new one. I've had fits with Pluto disconnecting on a PC. I bought a second one, and things were WAY worse. Posted question on AD forum and thought I'd share some success here to help someone else.

My question on AD forum "Pluto DC supply causing disconnect" is here:
https://ez.analog.com/adieducation/university-program/f/q-a/538047/pluto-dc-supply-causing-disconnect/397082#397082

AD person suggested increasing R88 to ~24.9k to disable the Vbus comparator on U15. He also suggested removing L7, but I had already shorted the grounds together on L7, so I didn't do that. My 2nd Pluto now works on three computers (it only worked on 1 of 3 before). I haven't looked at how changing L7 effects noise. I was just trying to get past making the thing usable at all. I was then playing with my two Plutos and decided to change R88 on the first one I bought (a year ago). I've had infrequent trouble with that one disconnecting. After changing the resistor, it would cycle in and out of connection; usb drive would come and go over and over. I then bridged the ground on L7 and that behavior stopped. I used to think (and maybe it still is) a temperature problem with my first Pluto. I had best luck with it if I had the cover off and a fan on it. I was suspecting bad soldering on the AD or FPGA parts. I had run a program to record the temperature, and it would crash at a consistent point (don't remember the temp). I was ready to have a tech at work reflow the BGAs. Then it didn't seem to be a problem as long as the cover was off, so I let it ride.

Pluto is fantastic for what it does for the price; but it's been one step forward, 7/8 step back for me with this thing. I pick it up for a while, and put it down for while, sometimes a LONG while. I finally got it going with LabVIEW.

[RoGeorge]

In my PlutoSDR, the culprit for disconnecting was the middle USB connector (data pins were cold-joint soldered).  Inspect the connector with a microscope or a very strong magnifying glass to check yours is well soldered.  Mine wasn't.

Resoldered the connector under a microscope (also changed the USB cable with a shorter one), and now it's all good, no more randomly LAN connections disconnections.

Never used it with other OTG USB devices, or with an extra power adapter.  Just the USB cable to the computer and the standard SDR firmware (with the frequency band unlocked up to 6GHz, and the second ARM core unlocked on the Zync).


LATER EDIT:
-----------------
Found out recently about a new SDR learning resource based on PlutoSDR and Python, will add the link here:
https://pysdr.org/

It is a very comprehensive SDR course yet very easy to follow, it covers all the important aspects of SDR without flooding the student with math, and without going into very fine details.  Has some practice and exercises, a few test questions, etc.

Parsed it recently, recommended.   

[wkb]

I bypassed the L7 GND connections with a short wire, that fixed the crashes once and for all.

Wilko
PA1WBU