… And should someone from the core Julia team control that group?
Outside scope of JuliaDSP?
I looked at the JuliaDSP group, but it seems to focus mostly on actual DSP algorithms.
The telecommunications domain also needs tools to design/model/observe analog phenomena which does deal with signal processing issues, including equalization with FFE/DFE, etc. However, I do not believe these tools would be appropriate for the JuliaDSP group.
Examples of Telecom tools
Creating eye diagram plots
PRBS bit sequences generators & “checkers”
Tools to simulate different bit/symbol modulation/demodulation schemes.
Tools to simulate different frequency multiplexing schemes.
It might even be useful to wrap some core DSP algorithms in a more useful form (like using a more constrained/application-specific APIs to model feed forward equalizers (which are basically FIR filters).
Currently Available Packages
There are at least two packages with overlapping/complimentary functionality that would work for a “JuliaTelecom” group:
Creating a new “Julia Group” I assume you mean Github organization is driven by the community, if there are enough packages in a domain to and the package authors are interested in collaborating it makes sense to create a new Github organization under which the packages are pooled.
I am the contributor of DigitalComm.jl. I completely agree with your different comments. Besides that, there is sill a large place to do (in the digital comm fields and for also upper layer) that does not directly fall into the scope of these two packages yet belonging the “telecommunication area”. The actual solution (everyone has their own package) can lead to a fragmentation of the proposals, lowering the potential impact and benefits for the community.
So a Julia group (if it is possible) is somehow a good idea. I am however not an expert on how the julia structure works, so I must confess that I absolutely don’t know how to create it (and make it visible from Julia repo). But, I will be very happy to contribute and move DigitalComm.jl to it.
I also don’t really know how to create a “Julia Group”. It would appear from vchuravy’s comments that all we would need to do is create a “Github organization”, and that we could do it on our own (without the intervention of the Core Julia team).
But it would appear that @vchuravy is suggesting we only should create such an organization if there are (currently?) enough packages - and my guess is that 2 packages might not be “enough”.
I suppose what I am really asking here is if this is one of those “if you build it they will come” situations.
I agree that 2 packages doesn’t really make an organization necessary, however 3 or more are worthy of one, in my mind. What other sorts of functionality/packages would be required for doing telecom things in Julia, that either don’t exist, or do and could be transferred into this org?
One example is that alot of what you do when designing telecommunication systems (and circuit design in general) is to do parametric tests to verify design robustness or compare circuit architectures.
I have a few packages that help with these tasks, though some of them are not even registered. For example, MDDatasets.jl:
Create a time-domain signal with simple RC rise/fall transitions.
Convert between time <-> frequency domains
Create single-pole pulse & step responses for your simulations.
Create a range representing time samples on a periodic signal for a given time range & fundamental that ensure you don’t have off-by-one errors that will affect the FFT, etc.
Automatically scales FFT results to correctly represent either frequency coefficients (periodic signal) or samples of the frequency spectrum (non-periodic signal).
My struggle
Many of my tools are generic, and could be in a more core library (not telecom-specific).
Many of my tools make use of MDDatasets.jl because this “Multi-Dimensional-enabled” module makes it much easier to perform tasks necessary for the telecom & circuit-design fields.
So, I sort of like the idea of building “glue” modules for “JuliaTelecom” that would provide signal-processing capabilities in a form that is practical for the design “flow” used by circuit designers, and architects of the telecom industry. That’s what I tried doing in CData.jl, which simply installs a bunch of said modules in your current Julia environment:
→ https://github.com/ma-laforge/CData.jl
I maintain a “Wireless” package, with multi-antenna fading channel modelling, equalization, codecs and the like, which makes heavy use of DSP.jl. I wasn’t aware of those other packages. Good to know they exist.
It’s unpublished at the moment. I’m an engineer not a computer scientist, so don’t expect Julia Base quality code. Also parts of it need more thorough testing (trying to get an undergrad project to help with that) and documentation is sparse.
With those caveats, it would be great to be part of a larger effort in this space, particularly if we could develop a common, streamlined API. I’ll aim to publish my package late next week.
You use telecom-type tools in radio astronomy? This is very interesting to me.
I admit I could see you using Software Defined Radio to de-modulate AM signals from space, I suppose.
But I don’t really expect you to use digital tools directly - unless you are looking for “intelligent” life. If so, I think that still falls under telecommunications, no?
Wouldn’t it be more likely that you would use DSP.jl base tools in conjunction with say, your own RadioAstronomy.jl package? (Sorry for the possible ignorance: I am in no means an expert here).
From my understanding, radio astronomers mostly want to generate images of distant galaxies using data collected at microwave frequencies (& possibly others).
If so, I would expect radio astronomers to require a whole different set of tools which likely build upon the DSP.jl package. I would also expect these tools to mostly be concentrated on generating 2D (maybe 3D?) images of the universe.
Many of the earth-observing satellites transmit images or telemetry back to earth using regular digital communications signals, or variations thereof. Other satellites can act as relays for amateur-band radio, of which some are analog and some are digital. I think such tools could potentially belong in a telecom group, or at least use some of its libraries.
Thanks for bringing this up, which is also my interest in this domain. I made some tools to decode NOAA weather data using an inexpensive SDR dongle. I think this is an interesting project for example for students.
Yes, this should be possible (assuming that you are also using an RTLSDR device). RTLSDR.jl now works with Julia 1.x and for instance I was able to decode a FM radio directly in Julia. I have not tried to use RTLSDR.jl with APT signal, but it should work.
Though I do agree that we do tend to call the field “communications” - and that most people are familiar with the “Communications” toolbox, my concern was not to confuse my group with other potential Julia groups. I mention this in one of my comments below:
And since I see Julia being adopted in so many fields, I could even see someone wanting to build a “Communications” toolbox for those who work as journalists, media editors, PR practitioners, staff writers, etc.
But even in more restricted terms, I personally feel that collecting all tools relating to the 7 OSI layers in a single Julia group would be a bit excessive… Though I am definitely open to hearing what others think on this subject.
Anyways, despite my reluctance to do so, I named my own package “PhysicalCommunications.jl” just because I mostly tend to work in the physical communication layer, myself.
And, for the record, I am not a particularly big fan of calling the group “JuliaTelecom” either - so I am all in to picking a better name/scope for this group.
Well, all natural signals are noise-like, so no ‘decoding’ is done. However, nowadays almost all receivers are SDR-type and DSP tools are heavily used (e.g. complex correlation and complicated inverse methods in EHT).
So I guess my comment boils down what do you mean with ‘telecom-tools’? Reading the thread now, I guess mainly demodulation (e.g. Costas-loops, QAM-systems etc.)?
So, perhaps there is a need for (at least) three groups: Telecom (or Communications), SDR and DSP? OTOH, these are somewhat overlapping?
so DSP would be OK…?