Would it be worth creating a "JuliaTelecom" Julia group?

… 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:

Sadly, it is much more difficult to find these packages if they don’t have the visibility of a “Julia group”.

When to create a group?

I don’t have tons of tools for this group yet, so I am wondering if it is appropriate to create the group now.

…Then again, would creating the group actually create the seed that got people to start contributing?

1 Like

Moving to package announcements. Not sure if I was reaching those who know what to do to start a new “Julia 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.

1 Like

Hello,

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.

RG.

2 Likes

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:

  • https://github.com/ma-laforge/MDDatasets.jl
  • Collect simulation results in multi-dimensional data structures (one dim. for each parametric test)
  • Perform automatic interpolation along the x samples (useful for continuous time domain results).

I also have a SignalProcessing.jl module to with the following features:

  • https://github.com/ma-laforge/SignalProcessing.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.

1 Like