I came across an odd problem getting my shiny new IC-7300 working for digital modes using Omnirig.
I set the filter to FIL1, the default widest filter, and the software (JTDX in this case) would transmit correctly. But after the transmission period when it went back to receive it would activate the narrower FIL2.
Here’s what’s going on…
Omnirig sends this instruction to the ICOM to go back into receive:
[pmDIG_U] ; These lines select USB-D for USB digital mode Command=FEFE94E0.2600.01.01.FD ReplyLength=15 Validate=FEFE94E026000101FD.FEFEE094FBFD
And according to the ICOM manual that should set the filter back to the “default filter”.
Trouble is nowhere in the manual can I see how to actually set the default filter for the mode.
So for now the best solution is to have Omnirig explicitly set us back to filter 1. I could just change FIL2 to be wider but then the filters get more confusing. Having Omnirig explictly set a filter when all I want the radio to do is go back revieve isnt ideal, but it works. To do this you’ll need to change this section in the IC-7300-DATA.ini Omnirig file:
[pmDIG_U] ; These lines select USB-D for USB digital mode Command=FEFE94E0.2600.01.01.01.FD ReplyLength=16 Validate=FEFE94E02600010101FD.FEFEE094FBFD
This is identical to the original except we explicitly set the filter as per the manual and update the replylength and validate string accordingly.
The simplest solution I’ve found to this is just to install libzmq. We can pull the latest code from github and install it. I usually install things in /opt but as the pip process will look for libzmq in /usr/local, we’ll install it in there this time.
There’s a simple way to resolve this but it’s not immediately obvious. BLAS (Basic Linear Algebra Subprograms) and LAPACK (Linear Algebra Something Something…?) are actually provided by the Solaris math and perf libraries, so installing those and setting a couple of environment variables will get scipy and numpy up and running for us on Solaris.
Python 3.7 is in more SRU’s. It’s best practice to use virtualenv to create a virtual environment to work on rather than installing into the system site-packages. I’ve seen a few users make a mess of the packaging system by updating the system python libraries with pip so please just don’t do it 🙂
Tested on a SPARC-M7 T7-1 kernel zone running 184.108.40.206.1.75.0
Suppose you have a dataframe with a column that has data in a string format and you need to transform that into a way that a machine learning algorithm can use. One good way is with one-hot encoding which will take the values in the column and create new columns with 1’s & 0’s representing the original data.
And that’s fine for machine learning. Your models and pipelines will just handle it once it added to the original dataframe. But what if you actually want to poke around in the dataframe and use the data yourself? Then it would be really useful to have the label of the column reflect what the data in it actually is. No problem just get the feature names from the encoder and rename the columns on the one-hot dataframe before concating it to the original frame:
This turned into a surprisingly tricky project… I have a signalink as my main audio interface box to my radios. It’s basically a USB sound card that connects to the data port of my radios and lets me use digital modes. It also has a couple of knobs to control levels. It’s great, I love it, but as it costs about €130 I wasn’t going to bu another one just for the convenience of not having to move cables around when I want to use it on a different radio.
But that is narrowing down the selection. It’s an AND. What were asking for is systems that are a SPARC _AND_ use NIS. And although we can use exclude() to reject some results it’s still and AND operation. What about an OR query?
What if we wanted to select systems that had either a T5 or a T7 processor? Then we need Q queries.
Q queries take the same form of argument as filter() & exclude() etc. but can be combined using OR operators. Here’s the Q query for our model that looks at the cpu_implementation for T5 or T7:
From time to time the International Space station transmits Slow Scan TV (SSTV) images as it passes overhead. These are relatively simple to receive and decode and sometimes you can get a downloadable certificate for decoding them.
The ISS has two digipeaters. One on 145.825 MHz and another on 437.550 MHz. The 2m being easier to use, as you don’t really need to account for doppler is the most popular. Though the 70cm was in widespread use when the 2m went offline a couple of years back.
While messing about with WSJT-X I noticed that it recommends setting the the mode to Data/Pkt if the radio supports it. My radio, a Yaesu FT-450D, does. But it didn’t work. Thus began a couple of hours down the rabbit hole of serial connections…