Open rolandturner opened 6 years ago
Relevant link: https://www.crowdsupply.com/lime-micro/limesdr
Note that the LimeSDR is simply a "usable component" wrapper for the LMS7002M chip and might be considerable overkill for producing an RF-enabled PSLab. It may, for example, be feasible to produce useful instrument with the LMS7002M but without the FPGA present in the LimeSDR. This would significantly reduce the data rate and therefore bandwidth that the instrument could use, but would also likely better than halve the cost.
Hi there @mariobehling @kumuditha-udayanga I am interested in taking this project as a mentored project for Fossasia 2020 mentorship. I am a third-year UG student from India. I have contributed for Mozilla and Chromium in their compiler plus I major in ETE so I think this is the best fit for me. I have enough experience tinkering with hardware modules and embedded C.
This great news!
I'd suggest that almost all of the work that needs doing is in software. Custom hardware may eventually be warranted, but there's much to do before then. A likely sequence might be:
Upgrade the PSLab app to be able to use the existing hardware to its full extent:
Implement all of the instruments required for the ARRL Lab Test Procedures Manual at MF, say: 472-479kHz (the amateur 630m band). Some of this will require various external RF analog pieces, much as one of the current PSLab kits includes various external sensors.
Retarget the app to do exactly the same things with the LimeSDR. One RX/TX port pair will work reliably down to 100kHz, which well and truly covers the 630m band.
Upgrade the app's capabilities to work over the entire LMS7002 range (100kHz - 3.8GHz). (Amateurs are generally losing their 3.3-3.5GHz allocations to 5G in most of the world, and there are no ISM band allocations in that area, so 2.5GHz may end up being adequate, but there's no harm in being able to operate over the full range supported by the hardware if that's easy.)
Review hardware requirements and consider whether there's value in supporting less capable hardware (e.g. the LimeSDR Mini) or even in developing new hardware.
Sir do we have any IRC/channel for the project related discussion. Also any begineer bugs I can fix in to get idea about codebase.
The preferred chat channel appears to be https://gitter.im/fossasia/pslab
My involvement is as someone with expertise in RF electronics. I'm not at all expert in PSLab's hardware or software; I believe Padmal is the lead developer of both. @mariobehling may wish to clarify.
This is definitely a "future directions" item rather than a current feature. Mario has invited me to document it for discussion.
My interest in the PSLab or something like it is largely about amateur radio, both for:
Hands-on learning about analogue signal processing
Most of a radio - whether transmitter or receiver - consists of a combination of analogue signal processing primitives (amplifiers, mixers, oscillators, filters, ...). There are well understood theoretical models and modelling tools for these primitives, however for people who learn best hands-on the electronics is tedious to experiment with at useful frequencies. For example, building a useful radio at the upper end of the HF band (30MHz) on a pluggable breadboard is impractical because the rows of parallel conductors in the breadboard provide stray coupling and parasitic currents that interfere with the intended operation of the circuit. Implementing the same primitives as circuits operating at 300KHz does not suffer the same problems with pluggable breadboards. Consequently, experimenting at low frequencies on pluggable breadboards with an instrument package along the lines of the PSLab makes sense.
The instruments relevant for amateurs that could be implemented on something like PSLab include (per the ARRL Lab Test Procedures Manual):
(Accessory items which may or may not make sense include attenuators, low-noise oscillators, GPS-disciplined frequency references, wideband noise generators.)
Building/testing useful radios
When building and testing real radios, the instruments required are largely the same, most of what changes is that the electronics gets more complicated and more layout-sensitive.
I am currently tinkering with a Lime Microsystems LMS7002M as present in a LimeSDR, with a view to implementing in software workable variants of as many of the instruments above as possible. This might be an interesting direction for PSLab to take, if supporting amateur radio use appears worthwhile.
Note that the LMS6002D is significantly cheaper at SGD 51 (vs. SGD 160), however: (a) with a lower frequency of 300MHz (vs. 100kHz) it's also not useful for most entry level amateur radio electronics which operates in the 3-30MHz range; and (b) it's single channel in and out which is very limiting; the LMS7002M's dual channels in and out are far more useful.
It may be that the LimeSDR is actually enough hardware and that this is really a software project for inclusion in the Lime Microsystems/Ubuntu app store, which would be even simpler. I'm not yet clear on whether this is true.
I'd add that there's reason for concern about precision of measurements (there's a reason that professional test gear is expensive!) but that as a tool for understanding what's going on, even an approximately accurate instrument is useful. When it comes time to make precise measurements, some combination of user measurement procedure (as distinct from clever software) and physical references (e.g. I mentioned GPS-disciplined frequency references above) is appropriate, and is frequently necessary when using professional equipment anyway.
Prerequisite Knowlege
C, Firmware development, KICad, Electronic measurement instruments
Possible Mentors
Roland Turner, Padmal M, Weitat Chung