Three pans - First steps success

Mark_WS7M

I'm working on my own client for not only mental satisfaction reasons but also I have some desires of things I'd like to have it do.

For a number of reasons I'm not using the FlexAPI library but doing this myself in C++.  It has taken a little time and learning but I have my code parsing all returns from the radio and I've implemented a UDP processing thread to service the UDP packets.  Currently I am only processing meters and FFT for the pans.

But... I have three pans working smoothly!  They need a lot of work still to bring them up to functional level but it is nice to see how this works.  It took me several hours today to try and figure out why my FFT data was all zeros.  Turns out if you don't send the command to tell the pan the X/Y pixel sizes of your display area the radio sends back a packet that looks right but the FFT data is all zeros.

Anyway here is a short movie of starting the code, discovering the radio then connecting and displaying the current three pans.  I preset these pans in SmartSDR.

https://dl.dropboxusercontent.com/u/7578983/ThreePans.mp4

EA4GLI

Great job Mark. Can't wait to see what you do once you have full control.

Frank, HB9FXQ

Well Done! I'm about to create a GNU Radio Source, so let me know if we could join forces - hi. 
Contratulations for the working FFT Display. 

Mark_WS7M

Hi Frank,

My code is using the Qt framework.  I have it working right now on both PC and Mac.  I have not tried Linux...  Send me an email at:  ws7m@arrl.net

Tim - W4TME

I like the peak/hold/decay feature.  

James Whiteway

Looking good!

Walt - KZ1F

Mark, is it on this end or was there no audio? I as trying to figure out Tim's comment on peak, hold decay.Qt framework sounds vaguely familiar but I don't know from how far back. As you may remember, I took a different route.
I started out trying to make XPSSDR look virtually identical to ssdr. I've drifted away from that secondary goal. Initially it was a primary goal. But all things change. I can't ask you much about how you accomplished things with QtF as I don't recall that much about it. I think my biggest hurtle was my last Swing app, Swing was Java's GUI framework before Eclipse and SWT, was in 2002. Since then the graphical world for me has been JSF and Jboss Seam. Currently I am working on making XPSSDR skinnable.
If you should have any questions or would like to confer, I'm reachable via my call at ARRL dot net.
I do have a Pine64 on order as that will be my shack control for when I run XPSSDR on the Android tablet.

Ross - K9COX

I like cats

Tim - W4TME

I [am] trying to figure out Tim's comment on peak, hold decay

Look at the spectrum.  On signal peaks (Peak), it leaves a "dot" at the peak signal level (Hold) that after a short time disappears (decay).

Mark_WS7M

Walt,

No audio... yet... I see the packets but I have not tried to decode them yet.

Qt has been around for some time.  (http://www.qt.io/)  I selected it for my project based on recent experience with it on an instrument control project where some of the scientists would request a test program, I'd get it working, then 3 days later they'd ask if it could run the mac and most of the time it was a simple recompile on the mac.

Qt basically has cool classes to do just about anything you want to do.  Their framework works on the signals/slots concept and these are cross-threadable and allow data to be passed easily between threads.

The code you see in the movie works like this:

Open UDP socket, connect datagram receive signal to a parser function
Parser function is called upon receipt of dg packet, decode, create radio object
Display radio object in listbox
double click on radio object, open new window, call radio connect method
radio connect method options tcp socket, starts udp thread connects signals for all objects including reading from tcp socket and udp thread
as data comes in parsers are called to store settings
certain things like pan emit new signals that travel up to the gui to update the pan

The signals/slots paradigm is very similar to windows messaging except the signals/slots are truly cross-thread capable and can carry significant pieces of data.

Qt has a class called QByteArray which is as the name implies an array of bytes. TCP socket and UDP socket can read directly into this object and the class has a ton of cool methods to manipulate the data.

I extended the class to have some easy methods like  toUint32( int index ) which would index "index" bytes into the array, pluck out the right number of bytes and convert them to an uint32 and return that value.  This made parsing the vita stuff simple.  Here is some code from vita parsing:

    m_start_bin_index = ByteOrder::SwapBytes( data.toUint32(index) );
    index += 4;

    m_num_bins = ByteOrder::SwapBytes( data.toUint32(index) );     index += 4;  I actually can swap bytes directly in the QByteArray but chose to have a static class method to do it.  I might move it later.  I will be in touch as I do have questions and wonder how things should be done at times when it comes to the radio and API.  I'm building this project about 50% as test driven development.  I have a unit test project and when I write a new piece of code, like the vita parsers I sort of do the following:  I connect to the radio and grab some data from it.  I then write a unit test to test the vita  function I'm creating to parse that data.  Kind of a mix of TDD and experimentation to get it working.  I looked at some vita libraries and they really were kind of overkill for what I wanted plus  in writing my own vita decoders I could better understand the radio data.

Mark_WS7M

That cat in the pic is my shack cat Haley.  She has been known to send code on the paddle actually.  She seems fascinated by cw and found when she pawed the paddle that the side tone came out.   I literally found her playing with the paddle one day.  Glad I had the power at like 2 watts!!!

Mark_WS7M

As I said the code is cross platform.  Here is the exact same code compiled and running on my MacBook pro.  Between the above Windows movie and what is running in the mac movie, one line of code changed to fix a Mac compile complaint.

It turns out the C++ compiler on the Mac is not tolerant about the use of temporaries created inside of function calls.   This compiles fine on Win:

MyDataArray.AppendFrom(  otherDataArray.mid(index,length) );

The Mac complains about cannot bind to a temporary.  So I have to change it to:

QByteArrayExt tmp = otherDataArray.mid( index, length );
MyDataArray.AppendFrom( tmp );

And both are happy.

https://dl.dropboxusercontent.com/u/7578983/ThreePansMac.mp4

Walt - KZ1F

Ah, now I understand. I agree, pretty cool, I agree. I've be using the tablet more and more so I couldn't see that far into the details or its just 5am for an old guy. Also, if people have been noting a dramatic uptick in typos in my posts, once again Android keypad and form factor. Thanks Tim.

Peter K1PGV

DARN nice work.  That peaky-hold dot is da bomb!

Peter
K1PGV

Mark_WS7M

Thanks everyone...

I hate to admit this but the peaky-hold dot is actually a bug.  It is proof that sometimes bugs can be useful!!!  Now I just have to figure out how I did that bug and make it part of the real plan!!!

M

Peter K1PGV

Jon_KF2E

Is it my eyes or are the peak hold dots only there for some of the signals?

Jon...kf2e

Tim - W4TME

To be done right, not all signals have PHD (peak/hold/decay) applied or the screen will look like a mess, but would determine the relative peak signal level in the display passband and apply it to a percentage of signals in a range below peak.  Currently this is how it appears.  I suspect the other "dots" are being overwritten by the next frame of signals.

Another cool visual effect is as the dots decay in intensity, the also decay in signal strength so they drop as they fade out.

IW7DMH, Enzo

Really a great job Mark! It seems a very promising project.
I am wondering if you are going to share your code. I like very much the idea of using the Qt framework and I would like to understand if, using QT, can be implemented some kind of graphical component suite.
I am not C/C++ skilled but, anyway, as I said in another post, I am planning to port my C++ code, written for Arduino, to the Qt multiPlatform enviroment.
If it could be useful, I have already implemented most of the "command" API.
The same question is for Frank, HB9FXQ, as I am interested in his great project as well.

73' Enzo
iw7dmh

Frank, HB9FXQ

Enzo, 

I'll keep you posted here in the forum about my progress, my latest trials with DAX Audio is mentioned here: https://community.flexradio.com/flexradio/topics/flexlib-radio-createaudiostream-dax-audio-encode-ho... 

...also pimped the debug UI to look a bit more fancy  


Regarding the codes, I'm in touch with Steve to see if the FlexLib licence allows ports... Then I'll plan to share my codes in a GitHub Repo. Fallback plan is to implement on IP level and skip FlexLib to not be bound to the LicenceTerms.

stay tuned
Frank (hb9fxq.ch)

DrTeeth

As a non-programmer, I would just like to say that I am amazed and jealous in equal measure at what the OP is doing. To me it is just like Einstein working out the size of the Universe on the back of an envelope or somebody working out the 10 year course of a satellite and only being 10 yards off at the end. Bloody magic!

Walt - KZ1F

Guy, it's a skill set, not entirely different than any other skill set. I, for instance, stand in awe of mechanical engineers. What they are proficient at isn't more worthy than what I am proficient at, it's just different.

Walt - KZ1F

Frank, there are several facsimiles of flexlib. Stu did one for ios, dogpark did one for Mac, I did a completely portable one. I don't know if Stu released the source for his, or just the binary. I will be releasing XPSLib in binary only form. I have no desire to open any of my source. A well done javadoc is an electronic programmer reference guide. If one documents the API there is no reason to publish IP.

Frank, HB9FXQ

Totaly agree: https://en.wikipedia.org/wiki/Software_craftsmanship

Mark_WS7M

I agree.  To me software is a lot like plumbing.  Really when it comes to software you have only two things:

data in
data out

A plumber deals with the same things.  He/she has to consider the volume of the "data in", how to best handle it (pipe type), He/she has to remember that each bend in the pipe creates friction and could slow the flow.

The environment limits how big the pipe can be. etc. etc etc.

Dealing with the Flex6000 radio is kind of like being a plumber.  You connect a few things up and get the data coming from the radio to plot on screen.  To do this I use a few pipes, fittings and tools.

The skill comes in how you use the tools, pipes and fittings.  A novice or inexperienced user either doesn't know how to use the pipes and fittings or chooses the wrong sizes or spends too much time routing the data to holding tanks then having to deal with those.

In my specific case I am a device programmer.  At the first part of my career I did database programming which is still plumbing.  You gather data from a screen and pipe it into the fields of database record.  But the design of the record and database are important to achieve reasonable performance.   I got bored of this pretty fast because once we got the real design work done it became drudgery to just maintain it.

After that I got into trying to control devices.  Again this is plumbing in a sense.  You send and receive data over various kinds of pipes (RS-232, ethernet, USB or whatever) and the device moves or does something.

The interesting part about this kind of work for me was that things don't happen instantaneously.  In database programming like I first did when the user submits the data it is milliseconds at most for the data to flow from the screen into your record and be saved.

In device programming, especially things that move, you have the time to move so you have to account for that and deal with it in your design and how you handle the instrument.  It gets even more challenging when you have several movers out there and you have to coordinate them.

I did a project where there was a SCARA robot in the center of the table and all around it were caddies full of disk platters.  At one point there was an independent gaging station that measured the sizes of the platters.  Everything had to work together and interact to make the system run.  It was a big challenge.  You can see this thing on my website at:   

http://www.systemstechllc.com/index.php/examples

Click on the ADE Autogager tab.  The cool thing about this project was getting everything to work together.  These things still run 24/7 in Malaysia.  The code is from 1994!!!  I still get a support request every now and then to help them out but to date nothing has been built that runs better than this tool.

So this is one thing I enjoy about attempting to program for the FRS6000 series.  I have ideas on what I want to do and again it is a big plumbing job to move all the data around to arrive at the result I want.

I think I have two primary goals with my project:

1) Station control.  I want integrated into my code, on the same page, controls for amp, antenna, log book, call look up, info look up etc.

2) Data analysis.  The FRS radios for me have opened the door to have my software try and interpret the data.  I'd love to have signals decoded right there in the pan.  While this can be done piping stuff to tools like CW skimmer and PSK decoders, why not have it all in one place?

Lastly it is a challenge and an enjoyable one.

Mark_WS7M

Enzo,
Thank you.  I do plan to make the code available but I'm not sure yet exactly how and when.  I'll keep everyone posted.

Ross - K9COX

Mark, do you recall ever working with a automation distributor out of Denver called MSI or ASI? (Motion or Automation Solutions)

Mark_WS7M

The name seems familiar.  We worked with a number of automation providers and distributors.   MSI in particular seems to ring a bell.

During the years I did that disk sorting project and others I did mostly development while another guy procured stuff so we might have dealt with MSI or ASI but I would not have been the primary contact.

Mark_WS7M

Did some clean up.  Added center scrolling and DBM scrolling.  I have not put in code to expand/compress the DBM range yet.  

I have put in code to zoom or compress the pan but it has some issues with the grid.

I spent some time to get slices looking a little better.  I can tune slices and move them quickly to signals.  I still can't control much about the slice yet.

Anyway making progress.  Oh ya... The wicked green and blue backgrounds won't stay... those are just clues showing me which surface is shining through.

PC:
https://dl.dropboxusercontent.com/u/7578983/ThreePansCleaner.mp4

Mac:
https://dl.dropboxusercontent.com/u/7578983/ThreePansMacCleaner.mp4

The clicks in the mac version are due to my use of the trackpad for mouse control.

James Whiteway

Great job Mark! Think I'll give my project up and wait for the release version of yours! :-) James WD5GWY

Mark_WS7M

Thanks James, but don't give up. Mine might crash and burn still...