I’m getting ready to build some Parallella-RF modules and I’m a little curious about the clock design in the schematics.
Is there a particular reason for using an on-board clock, rather than the external clock that the Myriad-RF uses?
I’m also trying to build these relatively cheaply to play around with, so is there a huge downside to plating the boards with lead free solder instead of immersion gold? I’m also planning on using Isola 370HR instead of the IT-180A, since the IT-180A requires additional material adders and lead time from my PCB fab house.
That’s very cool to hear! I’m afraid I cannot answer your questions, but I’ve pinged the folks who were involved in its design and hopefully someone should get back to you soon.
I’m curious whether you will be making any available to buy? I’d certainly love one! And I’m sure we could help with getting the word out if this is the case.
Also, do you have a particular application in mind?
Right now I am planning on making a small batch, probably just 8 boards just to play around with and see how they turn out. I’m shooting for them to be built and populated around mid-June. I’m having trouble finding some of the parts on the BOM, so I’m searching for more readily available/comparable parts to swap them out with right now.
I can definitely sell a few of them out of the initial batch so other people can also play around with the software side of integrating it with the Parallella.
I don’t have a very specific application, I’m just trying to make a really small and low cost SDR.
The clean crystal is required for LMS6002D synthesizers. That’s crucial for overall transceiver performance. It does not need to exactly the same part listed in the BOM. You can find some part with the same footprint, frequency range 21 - 40 MHz and low jitter 1.3 ps.
I guess the PCB stack can be modified but this implies some RF performance variation form standard board, such as Noise Figure, output power.
@RicardasVadoklis I’m guessing that if you want to be able to run GSM apps, such as OpenBTS and Osmocom, that the clock should be a multiple of the sample rate. E.g. 26MHz.
Brenna, worth bearing in mind ^^^^^^^^^^ if you fancy experimenting with GSM, as otherwise you’d need to do software resampling, which is something of a CPU hog.
I just got these boards back from my fab house today - took me a little longer to get to them than I originally thought. They look pretty good at first glance, but I’ll check them over in more detail over the next couple of days.
I’ve got a couple other projects ahead of these in terms of having them populated, but I’m hoping to get a couple of these out and populated in the next couple of weeks.
I am a coworker of Brenna’s. I am working on the interfacing, driver, and FPGA side of things. Currently we have basic receive and transmit functionality in place and the ability to work with open source software packages like GNU Radio.
The main issue we are facing right now is a large DC offset in the spectrum of measurement, even with all of the DC calibrations being done. There is about a -50 dBm DC signal in the spectrum of measurement, approximated by comparison to another input signal level. Attached is a picture of the spectrum in dBFS (dB with respect to full scale).
There is also the matter of the spur close to 906 MHz. There are other spurs and further investigation is needed for figuring out where they are coming from.
