User talk:Admin

Hey there, I just had a question. I'm rather conflicted about where to go with articles on signal families (e.g. Codan Data Modem, SSTV - Martin, etc) where the signal has multiple forms, sometimes very distinct from what's presented as a preview to users browsing the site. For some signals (ALEAutomatic Link Establishment 2G and ALEAutomatic Link Establishment 3G, SITOR-A and SITOR-B) I felt splitting them into 2 articles was the best way, where others (Coquelet, Piccolo) the signals were somewhat close enough to store in the same article, with the single preview to designate it for users.

For Codan data modem, there are very distinct signals, and it's difficult to make a single signal entry for just one of them, not to mention that it would be very redundant if I made a separate entry for each. Would it be better to have separate entries (however repetitive they may be in content) for signals of the same family that are very distinct, or keep them all together in one article, despite possibly creating the situation where users, looking for the signal, fail to find it because it was listed within an article, not on the home page with a preview waterfall? Thanks. -Cartoonman

I think it would be best to compress similar families of signals into a single article as you have been doing with Codan. Otherwise similar modes will clog up the front page. I also think compressing signals like SSTV into a single page would be good, since each variation is fairly similar. By the way, the page templates will change soon to facilitate some of the upgrades, so please watch out for the changes and let us know if there are any issues. - Admin

Yup, I was planning on consolidating all 3 of the SSTV modes into one article. I'll get to doing that as soon as I can. Thanks for the feedback, I'll watch out for the changes! Thanks! -Cartoonman

I tried to figure out how to do it myself but mediawiki's syntax and innerworkings eluded me greatly. I was thinking of a way where i could make the homepage display the frequency units in a magnitude-adjusted manner. An example:

• Bandwidth 10 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). -> Displayed as 10 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz).
• Bandwidth 9500 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). -> Displayed as 9.5 kHzKiloHertz (kHz) 10^3 Hz
• Bandwidth 50000 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). -> Displayed as 50 kHzKiloHertz (kHz) 10^3 Hz
• Bandwidth 2000000 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). -> Displayed as 2 MHzMegaHertz (MHz) 10^6 Hz.

The pseudocode I was thinking of implementing was:

if(Freq < 1000 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz).) unit = HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz).; 
else if(Freq < 1000000 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). && Freq > 1000 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz).) unit = kHzKiloHertz (kHz) 10^3 Hz;
else unit = MHzMegaHertz (MHz) 10^6 Hz;

So for values 0 < x < 1000, use HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz).. Values 1000 < x < 1000000, use kHzKiloHertz (kHz) 10^3 Hz. Values > 1000000, use MHzMegaHertz (MHz) 10^6 Hz. The inclusivenes/exclusiveness of < and > is up to you, can be arbitrary.

This would just be something to make it more readable, especially for bandwidth, Frequency isn't too affected since most frequencies are above 1MHz, but bandwidths vary considerably, and a good number of them are below the 1kHz mark, so using MHzMegaHertz (MHz) 10^6 Hz makes it difficult to read for bandwidth for all but the largest signals (XM, DVB-T, ATSC). I dont know how to do this in wikicode, perhaps you might. -Cartoonman

Will try an implement this suggestion. It's a little more difficult than just using wikicode as it requires some heavy modification of the wiki software itself. -Admin

I see the modification worked very well, great job! Not sure if it's slightly easier or more harder to do, but maybe something like:

if (freq_min == freq_max)
  disp freq_min
else
  disp freq_min "-" freq_max
if (band_min == band_max)
  disp band_min
else
  disp band_min "-" band_max

to make it neater on the home page, so for a given freq or band, if only one exists in the db, it will only show one of them, so you wont see things like 50Hz - 50Hz or 600 kHzKiloHertz (kHz) 10^3 Hz - 600 kHzKiloHertz (kHz) 10^3 Hz Would probably help Aco with gathering data from the homepage as well. When you have time :) -Cartoonman

Great job with the range fixing! Wikimedia's internal syntax is totally enigmatic to me.

Im sure you've noticed that i've been playing around with the Mode datafield, and I've been rather unsatisfied with the direction I wanted it to go to. At first it seemed like a good idea to change Mode to be the modulation of the signal, but when I began actually looking into each signal's modulation, it got a lot trickier to define their modulation. Just the VHFVery High Frequency (30-300 MHz)-UHFUltra High Frequency (300-3000 MHz) signals alone have FMFrequency Modulation modulation on top of whatever underlying modulation they use, not to mention OFDMOrthogonal Frequency-Division Multiplexing. It just gets very tricky, and I thought of just creating an entirely new datafield called "Modulation" that would be a property of type "text", like you have the property Mode already set, and it would be set up as an array, sorta like Frequencies is for each signal. You would use

 {{#arraymap:{{{Modulation|}}}|,|x|[[Modulation::x]]|, }}

to list the different modulations that the signal possesses. On the home page, you would make an additional column for Modulations, and use the arraymap to list the modulations the signal possesses (the number of modulations shouldn't usually exceed 5.). With this, I'll revert Mode back to what it used to be, so that we can differentiate between the modulation of the signal and the actual mode in which a user receives the signal in (and there is virtually only one mode to receive a signal in, unlike modulations a signal can have).

With this new Modulation property, users would be able to search the DB for a OFDMOrthogonal Frequency-Division Multiplexing-type of signal, or a PSKPhase-Shift Keying type, or a MFSKMultiple Frequency Shift-Keying type. It will also be a good addition to the list of required signal properties (frequency and bandwidth) to uniquely identify and categorize signals. It can also sift away signals like OTHOver The Horizon (very long range) and Codar that aren't modulated for users looking for signals that are only looking for signals that transmit information. -Cartoonman

Thanks i'll have a think about how this should be implemented. I would like it if people browsing could tell which mode to use for a particular signal for when trying to listen to a signal with say SDR#, but also have information on the underlying modulation. - Admin

Yea I was thinking to change Mode back into listing which mode to use to listen to the signal (USBUpper Side Band Modulation (Radio, referring to reception and modulation mode)Universal Serial Bus (Computer, referring to USB Ports and cables), NFMNarrowband Frequency Modulation, AMAmplitude Modulation, etc) and instead put the signal's own modulation into a completely new category, "Modulation", and have that list the modulations seen from the signal "QPSKQuadrature Phase-Shift Keying (2 bits per symbol), BPSKBinary Phase-Shift Keying (1 bit per symbol), DQPSKDifferential Quadrature Phase-Shift Keying, etc". Just makes it less confusing as it probably is now, and adds a signal's modulation info, something that signals currently don't really have a datafield for. -Cartoonman

Modulation is added now, though you've probably already seen it. Thanks for your work, i've made you an admin now as I've noticed some comment spam appearing and a rogue image upload happening every now and then. - Admin

Yes haha, I just made a few adjustments to the signal templates so that modulation now works like a list, which for some signals like DVB-T and Saab Grintek, that uses multiple modulations, is a must to accurately define it. Thanks, i'll help to keep the spam down. I don't intend to mess with the mediawiki code, particularly things I don't understand, don't want to break what isn't broken. -Cartoonman

I set up a nice category template you can add to the front page. {{Category Section}} is the template. Lemme know what you think. You can see a working example of it on my user page. -Cartoonman

Wow very nice, looks excellent!! I'll look it over carefully in the weekend and add to the front page soon. Do you think we should keep the big list on the front page, or just show the categories? I was thinking also of adding a category called "Common", which would have the most commonly found and asked about signals like POCSAG. Also was thinking of adding a category and signals for QRM/interference signals. What do you think? -Admin

Thanks! I was thinking of having a button for "All Signals" in case someone wanted to browse the full set, or if there's (probably) signals that dont fit in a particular category. (I think virtually all of then fit in at least one). This would make the loading time for the home page much quicker by removing the giant list of 200+ signals from the first page people land on. Aco should be able to query and parse that section to get the data he needs for Artemis.

I think the idea of Common coincides with some ideas I had about categorizing the active and inactive signals (because there's a lot of signals listed that aren't very active or not at all anymore). Maybe having an Active and Inactive category will fill that niche, since the signals most people probably ask about are the ones they see on the air right now. For the QRM/Interference category, it'll be a bit difficult to define that since technically any signal can be QRM if the operator's brave/silly enough, or if the reciever is unfortunate to be next to a high power transmitter. I know radars are the most notorious for interferring with communications, and I have a section for those. Most utility signals like telemetry stay away from communication bands, so they dont really QRM much. -Cartoonman

Okay i've added it to the front page now. Must faster loading now and not stressing the server too much any more :D. Let me know if something is broken. Do you have privileges to edit the front page? Feel free to do so if you think anything needs to be changed. If you like you can also set up a shared email and replace the rtlsdrblog one for people wanting to submit that way.

For interfering signals I was thinking more along the lines of definite interferers, like USBUpper Side Band Modulation (Radio, referring to reception and modulation mode)Universal Serial Bus (Computer, referring to USB Ports and cables) noise at 480 MHzMegaHertz (MHz) 10^6 Hz (seen quite a few people ask about that), or power supply noise, ethernet noise etc. "Real" signals wouldn't go in that category. - Admin

The front page looks a lot nicer and much faster indeed! A friend of mine who's very into web design and works with this stuff every day suggested moving some JS scripts from the head into the body to improve speed even more, maybe something to test. I have front page permissions, but I dont touch it too much. The only thing I've been trying to look into is collapsing the large comment section. It doesnt seem like the creators of the extension gave it a collapsing capability, and collapsing text isnt in MediaWiki's latest version. Maybe some direct way of doing it either with html/css or js. The shared email sounds great!

Considering the interfering signals, I think I can categorize those as "Interfering Emissions". Those are signals that technically shouldn't exist in the rf air but due to poor shielding/design, they leak. I've seen a number of those. Sure I can make a category for that. -Cartoonman

Yeah I was thinking about what to do with the comments section too, collapsing it sounds like a good idea, but i'm not sure how to do it. I'll look into moving the JS scripts and doing some optimizations as well. Also just noting that the category image table looks a little broken on mobile, must be something to do with the tables. - Admin

Oh, ha. That's because I brute-forced the table alignment. It doesn't readjust well on small width screens. I could find a way to make it come out a bit cleaner once a play around more with row and col span. I probably dont need to brute-force it given I changed the format from heterogeneous to rectangular. I'll look into it! -Cartoonman

I fixed the category image table, although wiki by default isn't great at scaling on small devices. It should be at least a clean table now. Tested on my phone, looks neat. -Cartoonman

Just a suggestion, I happened across this https://www.mediawiki.org/wiki/Extension:Lingo extension that allows for definitions for words and acronyms, which is pretty useful given this field of signal analysis is very heavy on acronyms like FSKFrequency-Shift Keying and OFDMOrthogonal Frequency-Division Multiplexing, as well as the Ham radio lingo like QRM and QSO. This *should* automatically make all words that are defined in a page like this have their mouseover text appear with the given definition. Here's a working example. There would be no need to comb every page to place tags, it should do it on the fly. I believe links can also be used on definitions but I have yet to test that. What do you think? -Cartoonman