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

@KajWiik: That seems to make sense to me.

Just for fun, I decided to check out what I (currently) get from Wikipedia’s “Telecommunications” page:

“Telecommunication is the transmission of signs, signals, messages, words, writings, images and sounds or information of any nature by wire, radio, optical or other electromagnetic systems”

From this definition, I could definitely see having “Julia Group” for “Telecommuncations” that would encompass pretty much everything that has been brought to light in this thread.

For example, it would probably place the SDR-related stuff in one of (possibly many) analog “telecommunications” modules. And yes, despite SDR being implemented with discrete-time-based machines (that introduce quantization noise due to the finite resolution of its internal registers), I consider the SDR radio itself as an analog component.

I am not certain yet how the functionality for such a Julia group should be split into different modules, but I do think it reasonable to have all that is discussed here under the same umbrella. So, I don’t necessarily think that “SDR” has to be moved to its own “Group”.

Then again, I am willing to change my vote if another practical solution is presented. I don’t mind @mbaz’ suggestion of creating a group called “communication systems” or “communication engineering” myself. As long as it isn’t too ambiguous, and that people can find the tools they need.

Personally, I am much more interested in the structure of the modules within. I don’t particularly like interdependencies between modules, and much prefer when dependencies follow a nice, clean (non-cyclical) tree structure. I also prefer a structure where you only have to pull in the elements you actually need. That makes it much less likely that changes in the included modules are going to break your code (even if the broken code isn’t really used by your solution).

I’m also interested in seeing a group like this form - if anything to focus all of the disparate development that seems to be happening in julia in this field and to prevent overlaps. I wonder how many different versions of the same functions we have between us :sweat_smile:.

I’ve created a strawpoll with quite a few possible names to help get this ball rolling: https://www.strawpoll.me/18702987/r

In other groups, a focusing structure that is typically used is the creation of a Base module that contains shared types and methods that are likely to be needed by multiple packages within the ecosystem. This helps with interoperability of packages, and allows for a lot of code reuse between packages.

This could contain stuff like the following, just to get some ideas down:

  • Equalizers
  • Filter design utilities
  • z-transforms
  • Laplace transforms
  • Fourier transforms
  • Plotting utlilities (Eye diagrams, IQ plots, Smith charts, Bode plots)
  • Decimation/upsampling utilities
  • Elementary functions and symbolic function manipulation (being able to write `conv(fft(s_t), DiracDelta(-tau)’ for example and have it return something sensible with the same number of samples would be nice.
  • AbstractModulation, AbstractEqualizer, AbstractChannel, AbstractSource, AbstractCodec…

I’d like to hear what others think about the creation of such a module, and any comments on what kind of functionality should be considered “Core” for a group like this.

I think that any modules that would benefit from using the Base repository would belong in this group -
I definitely don’t think that anything SDR related would be out of place.

Personally, I am much more interested in the structure of the modules within. I don’t particularly like interdependencies between modules, and much prefer when dependencies follow a nice, clean (non-cyclical) tree structure. I also prefer a structure where you only have to pull in the elements you actually need. That makes it much less likely that changes in the included modules are going to break your code (even if the broken code isn’t really used by your solution).

Exactly how a telecom ecosystem should be factored is a question that is difficult to answer at the moment - this may become more readily apparent once the ecosystem becomes more interconnected.
A structure like the one used in JuliaDiffEq seems sensible - there they have an overarching package that reexports several core modules, which all have any shared types and methods defined in DiffEqBase. Any packages implementing more niche functionality can be optionally imported, but since all common types are defined in the same module they remain compatible.

Here is some more information on creating github groups, it looks like it would be quite simple to get started once a name is decided:

2 Likes

Was there an outcome of these discussions on setting up a Julia Telecon/Communications group?

Sorry. I haven’t been keeping up. I’m not actively doing development in this area right now. If you’ll notice, I only have one small Telecom-oriented module. The rest of my work focuses on parametric analysis:

GitHub - ma-laforge/CMDimCircuits.jl: Parametric analysis/visualization of model/measurement/simulation results
(This module absorbed my previous SignalProcessing.jl & CData.jl modules)

Good news

The good news is that there appears to be much desire to create some form of organization for a “communications” group.

Many people appear to have something to contribute that would warrant a new Github organization.

Consensus: the bad news

I have to admit, I don’t really know how to create a github organization - but I would give it a try if we had some sort of consensus.

  • Right now, we don’t seem to even agree on a name for the group. So that sort of stops me from even trying.

Moving things forward

That being said, I think something should be done in order to get the ball rolling. If people agree (maybe if I get sufficient “likes” or approving replies), I can get things to start moving by creating a new Github organization.

My plan

But since we didn’t have consensus, my current plan would be to name the organization:

  • JuliaTelecom

This seems to best match the naming “convention” we have for other groups
Julia GitHub Organizations

Please note that there is already a “JuliaDSP” in that list (for those who are unaware). But, from what I can gather, this organization houses more core signal processing algorithms - and doesn’t deal with analog issues. For example, it doesn’t appear to be the place for an algorithm that generates eye diagrams.

Once built, I can:

  • Transfer PhysicalCommunications.jl to that organization (hoping I don’t break how it is registered in Julia’s General registry).
  • Add other members to the group.

My limits

Sadly, I probably won’t have the time to be an active member at the moment. But that doesn’t mean I can’t help to get things up and running.

2 Likes

Hello @MA_Laforge
I completely agree with your statement. The sooner the better and a github organization seems to be the most suitable solution.

  • Agree with JuliaTelecom. I think that this cover well the different contributions envisioned here, different from pure digital signal processing and still with place for specific packages. Note that DSP is still one part of a Telecom system is. As you said it does not cover analog parts, but it also not cover higher layer (Forward error corrector, waveforms, MAC layers and so on).
  • As soon as it is create, feel free to add me in the group
  • I will move DigitalComm.jl to the organization (same hope that it will not destroy everything :slight_smile:) .

Note also that from my side I have not plenty of time for package development at the moment but still plan to do some Software defined radio (SDR) binding packages that would definitively be part of this ecosystem. We can maybe add @dressel into the discussion as he has done the RTLSDR.jl package.

I started to look into creating the group. I started creating the group and got the following options:

Sign in to GitHub · GitHub

I chose to “join for free” despite wondering if it would be a good idea to have “required reviewers” (Team package).

The next page brought up an interesting issue:

Namely that I can assign it to either a “business or an institution” or my own account.

  • I wonder if there is a way to have it assigned to a Julia “buisiness” or something.
  • Otherwise, I guess I would be the owner of this organization - which is a little strange.

Anybody have insights here as to how I can ensure this will be a collaborative organization instead of being assigned to me personally?

Is it possible that once I add other managers to the account, I effectively no longer become the sole “owner” of the organization?

2 Likes

Sorry to bother you @mkborregaard, but you probably have some experience here, being part of the JuliaPlots organization.

Do you know any tips for creating a new organization (see my post just above)?
I just want to ensure it will be collaborative and not “owned by me”.

This is new, it used to be simpler. Anyway, it’s easy for you to add owners / admins of the org later, and the creator of the org has no particular privileges. So I’d just go ahead and associate it with your personal account and then add people who contribute as owners.

3 Likes

Thanks for the quick reply @mkborregaard. That’s reassuring.

I started our “github organization” and everything looks fine:
https://github.com/JuliaTelecom

I transferred my own PhysicalCommunications.jl and invited you, @RGerzaguet.

As far as I can see, there were no issues transferring my package. It is still available through my personal github address, but that now links to the new repo in JuliaTelecom.

I can still add the package, as usual from Julia with no visible problems yet.

1 Like

@MA_Laforge This is great news; thank you for setting it up. I have some telecom packages in different states of development; I hope to tidy them up and contribute them soon.

1 Like

Sounds great!

Also: I’m planning to list useful packages/tools that are not yet part of JuliaTelecom in the following repository:
GitHub - JuliaTelecom/JuliaTelecom: Greetings & telecom-related tools

I’ve already added a link to RTLSDR.jl and I think I might want to add links to other, non-julia ressources such as those listed on my web page:
Free EDA | ma-laforge
Modelling Tools | ma-laforge

But I may just add links to those pages so I don’t have to maintain 2 lists.

Anyways, if you want to guide people to your packages without going through the process of transferring them to JuliaTelecom, just let me know.

…or maybe you can open an issue/PR in the JuliaTelecom repository?.

Ok: I did not quite like the default Github-generated logo for Julia Telecom, so I created my own:
image

The logo is not set in stone, but I though it is fairly representative of the telecommunications industry.

  • Julia triangular shape works out well for a satellinte uplink/downlink diagram.
  • Fiber optic channel represents wireline.
  • Relatively simple geometries.
  • Respects the underlying logo style from other Julia groups

I admit there are no cell towers, but I think the satellites capture the wireless aspect of telecom sufficiently.

…And I want to leave options for a “JuliaWireless” group - if ever the scope of JuliaTelecom becomes unmanageable.

If you think you have a better idea, feel free to make a suggestion. I uploaded the .odg file (Open document-compliant) if you want to start from there:
https://github.com/JuliaTelecom/FileRepo/tree/main/logo

3 Likes

I think it’s great!