Thursday, March 16, 2023

Sunspot Number

I've been interested in the data behind the Sunspot Number calculation.

I asked one of the research observatories about the precursor data (g and s) which solves the equation:

R = k (10g + s)

Where:

g = Number of sunspot groups in the solar disc
s = Number of sunspots in all groups
k = A factor usually < 1 which characterizes the method of the observation.

What we get on "solar weather" report is the R value.  But we don't have access to the s and g value.

So, I asked about that.. And here is the response from Dr. Laure Lefevre from Royal Observatory of Belgium - STCE.

We distribute the international sunspot number (what you call R) computed from our network of stations with the formula you mention. However, we cannot distribute the data from the individual stations that enter into the calculation as these data are specifically handed out to SILSO for scientific purposes and are protected by the European GDPR laws. 

So it is normal that you can only find the daily R on our website. The latest data is only estimated: https://www.sidc.be/silso/eisnplot   The data until last month (February 2023 in that case) is available here: https://www.sidc.be/silso/datafiles

Space weather, solar weather is terribly interesting to me.  In my line of work cosmic radiation (not from the sun) with near relativistic energies is critically important to mission success.  Solar weather cannot be ignored either for many parts of the mission risk that we deal with.


Wednesday, March 15, 2023

It was Mr. CME in the Garden with the Antenna Switch!

That's what it was.  It was the CME that took out the Nothwest Ten Meter Net on Tuesday (UTC March 15, 2023)


At around the time Jim, K7NCG was responding to Al, KB7TBC on the NWTM CW Net, the CME shutdown the band -- sorta.  It washed Jim's normal S9+ signal down to S1.  It also had the effect of washing out his modulation.   What was a laser focused zero beatable signal became a mush.    I know Jim's rig is capable of amazing things, and delivering mush is not one of them.  Hi-hi.

That sort of explains the modulation of Jim's signal on my horizontally polarized antenna.   Now it has me wondering if I heard the extreme effect due to my long wire and the rest of your experience was limited because you had vertical polarization antennas.   

Anyway, something to puzzle over.   I really wish I had my audio recorder setup to capture it.  It was a perfect wash out of the band.



Tuesday, March 14, 2023

One Less Thing

One less DXCC entity to worry about for a while.

In today's mail, the XYL handed me a letter addressed from Germany and inside was the QSL card from FT8WW.

I had worked Thierry on 20 meters CW and it all looked good in the log.  So the card arrived and it's a nice two panel card with some great photos of the DX location.    Many sponsors contributed to the FT8WW expedition as far as I can tell from the list of logos in the card. 





Wednesday, March 8, 2023

Kitted the QSD

The Quadrature Sampling Detector that I found has been kitted.

I know what parts are on the QSD but I don't have the schematic yet.  Soon, I hppe.

The main thing is I think I have the part-list (BOM) made and on order.

So once I get the schematic, then I can start to stair-step my way towards a QSD that might work.  It might not work but that's part of the fun too -- to figure out what he heck is supposed to happen.

Knowing how I do things I'll probably end up trying many different designs for a QSD and end up with different versions of something that will teach me.

The difficult part to find was BF545B, SOT-23 since it is longer made.  But the data sheet had the clues to find a close work-alike JFET.  I think so at least.  I'll experiment with the part in isolation to see if those choices were correct.

SDR.   Seek Device Replacements.


SDR

I was never big on SDR.   By that I mean, I was never big on the idea of a PC that controls a radio.  I don't mind too much if the radio itself has some systems that are characterized as SDR.  It's a fuzzy line these days with a lot of modern rigs having DSP.   Even my Elecraft K3 has some components that are characterized as being part of the SDR signal path.

I can't argue with that, as long as I have knobs to turn and displays to read.  But a headless radio that is only controlled by a PC is something that I cannot do.

So it is interesting that lately I've been looking at some of the homebrew SDR projects that are out there.  This is a field that has a level of maturity now that it's (seemingly) straightforward to begin exploring.

One project in particular has caught my attention.  The T-41 SDR based radio kit that has been advertised by the 4-Square QRP Club

The issue with this kit is that the parts (BOM) are lagging because of supply chain issues getting the parts.  That is understandable and not too much a concern.  The folks who are driving this project are doing an excellent job of managing the situation and I'm completely confident that those who are lucky enough to secure a kit will be pleased.   I'm not on "the list" because there is no list.  It'll be sort of like a Pile Up to determine which lucky ham can get a kit.   I'm hopeful, but not banking on it.

In the mean time I am looking into their software and made a recommendation that they put the source code for the BSP on GitHub, which they have done recently.   But I think there needs to be some tweaking to the repository and other things to make it easier to access (i.e., build).

I've forked the repo and will be making my contributions through PRs in the days/weeks ahead.

In the mean time of that I also have been looking into the basis of the SW package that they are using and stumbled (perhaps incorrectly) across a few things.

Namely, the core software seems to be based on (or influenced by?) an SDR project from DD4WH.

On that repo, I found some key information -- 

The basic HW platform that would be needed, and some of the hardware systems that go along with it -- like the display and SDR Quadrature Sampling Detector, and some other things.    Unfortunately the SDR QSD they are using in that project is out of stock in the supplier so it will be a bit of a challenge to replicate that design.

Also, I am going to have to upgrade the HW platform from Teensy 3.6 to 4.1.  The MCU are close enough.  The ARM Cortex M4 and ARM Cortex M7 aren't that dissimilar except for some underlying IO and addressing of registers that are specific to each specimen.  I'm not too worried about that port-over.

The Project then I have started is trying to bootstrap a SDR from what I can get my hands on and adapt from the existing repositories (the ones listed above) to make something from nothing.

I have two things on my side.   One is a career worth of experience in embedded software.  (Day job is making rocket engine controllers and other embedded software systems for space, so I'm not at all daunted by the port of the embedded side of things).  The other plus is that I have a lab at home that has all the tools and test equipment I'll need to build it and test it.   It'll be interesting!

At the end of this, or at least at a major milestone of this Project is copious amount of documentation that I plan on producing that will help anyone else "start from zero to get to SDR".    I think a lot of the projects are put together very well.  One critique is only that the projects aren't (apparently) really designed to be portable (not physically portable -- I mean adaptable to slightly different MCU based systems that are fundamentally very close).  That's the work I hope to zero on.  I may not know enough yet about the actual SDR code base to make that statement correctly, but I think I'm right from the things I've read so far.

We wouldn't be in this position if it wasn't for the excellent work and development by MANY who have strived to make SDR projects something for the common-ham.  I do sincerely appreciate the work that has been done and have utmost respect for their work.

I am going to try to carry things further.  As the Old Bard says, "Build on the Work of Others".

That's exactly what I intend to do.

More later.



Monday, March 6, 2023

Seen in the Wild

That poor Sasquatch, treated again like a marketing tag line for yet another purpose.

This time, the load bearing wall for the super structure of the Pacific Northwest QRP Club Sasquatch Stomp.

Interested, read on.

I got my highly prized Sasquatch Number from the GRAND CRYPTID.  And this number is for life.

I guess I can share it.  0x2D9,  001011011001, or 01331.

Be in awe!  ;-)

I look forward to working the QRP Sasquatch Stomp.   The score card system makes absolutely no sense at this time, but I will do the math later and figure it out. 

STMP, apparently.





Don't Sell the SB-200

Who knew the supply chain would be so wedged up that parts are nearly impossible to get.

I had once owned two SB-200's.  I bought them off Ebay.  They were basket cases.  I re-did everything in them.  All new PW, valves, all the kits and improvements. Made them rock solid again.  And then what did I do?  I sold them for what I thought was a profit so I could fund my other amplifier projects.  I haven't had the SB-200s in the shack for at least 12 years.  I sold them to local hams, Face to Face, glad they went to a good home.

I had no way to know that those SB-200's would be worth a small fortune today -- even if basket cases.

In this age of "supply chain woes" for silicon, do not sell.  Do not sell your rigs.  Do not sell your gear.

It is either just a repair away from working again, OR it is a source for spare sparts.

I tend to collect radios, tuners and what not.   I can't help it.  There's always a chance that I can fix it.

My collection of three (3) HO-10 monitor scopes should yield enough parts to make one of them run correctly again.  You would think.

As I try to get my new shack booted up, I cannot run QRO until then.  So I'm stuck with 100W -- which is fine.  I do just fine on 100W with my horizontal Sky Loop antenna.  I can definitely hear them better than they can hear me, though.   

Anyway, just a thought I had lately.  Keep the gear.   If you really do not have a use for the gear find a way to help your friends who might need it.   Think globally, act locally.  Is that how the phrase goes?


Sunday, March 5, 2023

What it's all about

Had a great QSO with a contact that I last spoke to in 2010,  Neil K6KWI.

He mentioned SOTA and POTA and sent me a graphic to show just how many possible POTA to work from in my neck of the woods.

I haven't called CQ that much on the bands until recently and when I do, I get a good surprise now and then like the contact with Neil.  

The graphic shows some good parks that I know of on the peninsula.  Near the Olympic National Forest and Park system.  I think I'll plan something -- when the weather gets a little warmer.


I think I might investigate this a bit further.

The links Neil shared are:




Wednesday, March 1, 2023

The query for DX




I wanted a query that shows just how far there is to go, chasing DX.  

But for anyone to use this there are some prerequisites.

For the impatient, I put the whole kit of script/SQL on a repository. Clone this and modify to suit.


First, you are using Logging Software that stores your QSO's in a SQL database (MySQL, etc. -- as long as it can comprehend SQL statements)

Second, when your Logging Software stores each QSO, there is a field in that record called country
and a field called callsign.   The country field is the name of the DX entity, not the ID number of the entity. So for example, for United States, the value of country is 'United States' not 291.

The callsign field is self explanatory.

Next, you'll need another table.  I call it dxcc.  I had to make it.

It is a table of all of the DXCC entities.
It has this schema:

mysql> desc dxcc;
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int unsigned | NO   | PRI | NULL    | auto_increment |
| name      | varchar(150) | YES  |     | NULL    |                |
| cqz       | int          | YES  |     | NULL    |                |
| ituz      | int          | YES  |     | NULL    |                |
| continent | varchar(4)   | YES  |     | NULL    |                |
| pfx       | varchar(16)  | YES  |     | NULL    |                |
| dxid      | int          | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

So for instance, the table dxcc contains records like this:

mysql> select * from dxcc limit 5;
+------+-------------------------+------+------+-----------+------+------+
| id   | name                    | cqz  | ituz | continent | pfx  | dxid |
+------+-------------------------+------+------+-----------+------+------+
| 1039 | Sov Mil Order of Malta  |   15 |   28 | EU        | 1A   |  246 |
| 1040 | Spratly Is.             |   26 |   50 | AS        | 1S   |  247 |
| 1041 | Monaco                  |   14 |   27 | EU        | 3A   |  260 |
| 1042 | Agalega & Saint Brandon |   39 |   53 | AF        | 3B6  |    4 |
| 1043 | Mauritius               |   39 |   53 | AF        | 3B8  |  165 |
+------+-------------------------+------+------+-----------+------+------+

The critical things are that each entity has a name (stored in the field name) and what is important is that your DXCC table that stores names of entities uses the same naming convention as your logging software.    I won't go into how to reconcile that, but that's a requirement also.  The easiest way to generate that list though is either to snag the ARRL DXCC List or to use your Logging Software and poke around to find where they have the data for "all known DXCC entities" (not just worked DX but all known DX as per your software).

The dxid field is just the ARRL assigned DX entity ID number, for future reference.

Anyway.

With that in hand you can run this query:

SELECT   d.name AS dxcc_entity,  
         COUNT(l.callsign) AS callsign_count   
FROM     dxcc d   
LEFT JOIN log l ON l.country = d.name   
GROUP BY d.name ORDER by 1

It's going to count up the number of records (if any) that are produced by an outer-join between the dxcc table (the table of all DX entities) and the table Log (which is the name I use for the Logging Software).

When for each DXCC entity (by name) there are any records in Log (stations I've worked) that share the same name, it adds to the total for that DXCC entity.   The GROUP BY establishes that this aggregate (count) is done per country in table dxcc table.

What's the result?    It tells me how many contacts per country.   What's next is to modify the query to tell me number of contacts per country per band.

For those who do their own software, logging tools, etc..  It might be useful to you.

Update:  For the 5BDXCC query, there's a need for a table that aggregates the totals per DXCC entity.  SQL (doesn't matter what the RDBMS is) is not quite suited for what people call "Pivot Tables" in Excel.  It's possible, but it's more tedious to work out the query.  Instead I created another table to perform the function of the pivot:


mysql> desc sum;
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int          | NO   | PRI | NULL    | auto_increment |
| name      | varchar(150) | YES  |     | NULL    |                |
| cqz       | int          | YES  |     | NULL    |                |
| ituz      | int          | YES  |     | NULL    |                |
| continent | varchar(4)   | YES  |     | NULL    |                |
| pfx       | varchar(16)  | YES  |     | NULL    |                |
| dxid      | int          | YES  |     | NULL    |                |
| m160      | int          | YES  |     | NULL    |                |
| m80       | int          | YES  |     | NULL    |                |
| m40       | int          | YES  |     | NULL    |                |
| m30       | int          | YES  |     | NULL    |                |
| m20       | int          | YES  |     | NULL    |                |
| m17       | int          | YES  |     | NULL    |                |
| m15       | int          | YES  |     | NULL    |                |
| m12       | int          | YES  |     | NULL    |                |
| m10       | int          | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

First thing to do is fill in the sum table with the names and attributes of the dxcc table.
We will get to the totals (m80, m40, m30 etc..) later

INSERT into sum
(name, cqz, ituz, continent, pfx, dxid)
SELECT d.name, d.cqz, d.ituz, d.continent, d.pfx, d.dxid
FROM dxcc d;

After that, per each field m160, m80, m40 and so on this query needs to be run, but with a caveat.

You'll need to instrument some embedded SQL to iterate through all DXCC ID's (they are stored in the field DXID.  So for instance the lower-48 is 291, etc.)

So, wrap this stanza in a loop that iterates over all of the DXID where each DXID is N.

UPDATE sum s
SET s.m20 = (
SELECT  COUNT(l.callsign)
FROM    dxcc d
LEFT JOIN log l
      ON l.country = d.name
      AND l.band = '20m'
GROUP BY d.pfx, d.dxid having d.dxid = N)
WHERE s.dxid = N

You cannot use this literally.  It's meant for embedded SQL.  Your embedded SQL wrapper needs to specify the values for N.   They are integers.  I could show you how I wrap it, but I'd rather just email it to you than further cloud up this page.  If you're really interested, just ping me.

But that's not all.   That just sets the "20 meter" total per DXID.  If we want to do all of the bands, we modify the statement above to look like this instead.  This is one statement.  We are SETting on several fields per the condition in each sub-query finally "WHERE s.dxid = N".  I used some perl code to generate the SQL statements and then shove them into the RDBMS.  If you really want to run with this, and need help just ping me.

UPDATE sum s
SET
s.m20 = (
SELECT  COUNT(l.callsign)
FROM    dxcc d
LEFT JOIN log l
      ON l.country = d.name
      AND l.band = '20m'
GROUP BY d.pfx, d.dxid having d.dxid = N),  /* note comma */

s.m40 = 
SELECT  COUNT(l.callsign)
FROM    dxcc d
LEFT JOIN log l
      ON l.country = d.name
      AND l.band = '40m'
GROUP BY d.pfx, d.dxid having d.dxid = N),  /* note comma */

/* and so on, for each band.  Cannot name fields '80m', so the
   field is 'm80'.  I didn't bother creating the records for 160m
   or 6m since I don't work a lot of DX on those bands.
 */

WHERE s.dxid = N;
/* That is the last line of the one statement. It's a long SQL statement to update all of the per-band fields.  You don't have to do it in one statement, but it's just easier for me. */


Finally, when all is loaded into the sum table, I can generate the HTML for the "Wanted List"

This page is generated via more software (a simple perl script that is based on the data in the sum table above.

A sample.  I chose to use grey background not traditional "red" because for me there would be too much red (hi hi).






Things happening

It has been a busy few months since I hung up my software-spurs. On deck -- DX'pedition for Lord Howe Island Lord Howe Island (July 202...