rms-support-letter VS gnuradio

Richard Stallman, the patron saint of open source software, the author of the GPL, and founder of GNU, got fired over some bullshit trumped up accusations. He pointed out a technicality, but that was too close to dissent, so they rallied the mindless hoard and got him fired. I'm salty over it.

There were some issues made earlier, then issues were removed for that repo. One such issue was at https://github.com/rms-open-letter/rms-open-letter.github.io/issues/951 but it is no longer available. You can find a screenshot of it linked here https://github.com/rms-support-letter/rms-support-letter.github.io/issues/1338 -- the saved image is here: https://user-images.githubusercontent.com/73961250/112379336-f1f6a180-8cdf-11eb-8571-f6fd05784284.png

For lack of a better term, https://github.com/rms-support-letter/rms-support-letter.git... look a lot like a cancel-culture honeypot than anything else.

Someone opened an issue about this, maybe you could take a look:

https://github.com/rms-support-letter/rms-support-letter.git...

Speaking of OSI, Eric Raymond signed the RMS support letter. That just about says it all.

It is telling that these cowards from TOR have limited replies to that tweet. It is a pity that such important project is in such bad hands.

Anyway, just signed rms support letter [1] and suggest you do the same.

[1]: https://github.com/rms-support-letter/rms-support-letter.git...

People from that "cancel letter" are removing issues when others tell them they are wrong. Their argument seems to be that there's already a lot of votes, so misinformation should stay based on that. People from the "cancel letter" also accept new translations, so I believe the misinformation spreads that way and many people who weren't informed enough about RMS will have a different picture after seeing only one side of the conversation. They act weird enough to earn a parody letter.

There are threads proposing to link to further discussions, however IIUC the maintainers of the support letter want to prioritize the freedom of association over defending Stallman's opinion, i.e. even if he has unpopular personal opinion, the FSF has the rights to choose its board members.

In gr-dtv transmitter examples for Gnuradio, I see some times people use a resampler block before the RF hardware sink. Say our sampling rate is ~9.14Msps which satisfies the Nyquist criterion because our samples are complex numbers.

2.1. Thanks for that tip, I forgot that I was able to check the source code of the WBFM Receive block. As you have said, there are mostly the same. There are some differences between how values are picked. The WBFM Receive block would be a synonym of Quadrature demod => Fir Filter (decimation => Low pass filter) => FM Deemphasis. 2.3. My question there is why 10 and not 20 or 100. I understand that the idea is to reduce the sample rate asap, but what I don't understand is why those values were picked and how can I understand what would be the "correct" or "best" value. 2.4. I'm not fully understanding what you said. If I check the WB FM recieve source code the values that are supplied as the cutoff freq and transition width of the Low pass filter differ from the one of the example. The webfm would apply a sample rate / decimation / 2 - sample rate / decimation / 32 as a cutoff freq and a sample rate / decimation / 32 as a transition transition width. Calculating those values would end up in different that the ones supplied in this second example. Again, is there a rule of thumb to pick these values?.

Gaussian filter is used only on the tx side, so specifying bt in the receiver makes no sense. Take a look at gfsk mod/demod blocks implementation: https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/gfsk.py

GNU Radio

Here's the filter coefficients used for the GNU-Radio interpolator block to get you started. This is a 7th order interpolator (i.e., 8 FIR taps) with very good performance. Each "row" of the array sets the delay in steps of sample_time / 128.

From their README: “open-source software development toolkit that provides signal processing blocks to implement software radios.” https://github.com/gnuradio/gnuradio