Three pans - First steps success

James Whiteway

I wouldn't really give up. What fun would that be? I am impressed with all that you have done. On question, are you hard coding for each pan object? Or are you querying the radio for the number of open pans or available pans from start up of your application, and then displaying the results? The test app I sent you some time ago does not do that. Instead it is hard coded for a single pan. I did that trying to learn how to display a panadapter first. I know the proper way is to query the radio for the number of available pans and get a count of those in use. The Presistance database makes that data available . If I open 2 or more pans in SSDR, then close it and run that test app, all of the pans from the SSDR session will be sent to the single display area in my app! Looking at the data in onDataReady event, one frame at a time from each running pan is being sent one after the other. Really messed up the display! My new test app does not do that. (hope it stays that way!) Anyway, I said all of this wondering which method you are using, hard coding each one up to 8 ( for a 6700) or just building them dynamically (on the fly) depending on the panadapter count from the radio? James WD5GWY

Mark_WS7M

Good James... Remember: Never give up, never surrender (in the famous words of Tim Allen from Galaxy Quest). My code is reactive meaning it receives all the values from the radio from all the sub ... commands and if it sees a new pan appear it creates a display object for it. So no, they are not hard coded. My code currently is based on the concept that the radio is going to send me data. Based on the data I get my code will do certain things. Most of the time the data is simply stored so in my radi object for example I store every property sent about the radio like model, ip, etc. Anytime they come in I store the value and I "emit" a signal saying a property changed. In the cases of pans I get data back for each pan because of the "sub pan all" command sent at connection. So data comes back from the radio in the form of: display pan 0x40000000 prop=value prop=value etc... I parse this and have a list of pan adapter objects. At start there are no pans. I parse the above data, look for a pan 0x40000000 and if I see one I just update it with the data otherwise I create a new pan object and populate it with the data. The act of creating a new pan object in my code emits a signal I call "newPanAdapterAdded" and it passes the 0x40000000 id. Other code more in the display section of things reacts to that signal and creates a new pan display object and attaches it to the newly created pan. Currently my code cannot create a pan adapter. I know how to do it but just have not built the UI to allow creation of one yet. But it should just work. Any pan added will create one of those displays you see. The pan displays also query for slices that belong tot he pan and display the appropriately. I think for your app you need to look at the pan Id, the 0x40000000 thing as it will change with each pan. You'll need to handle the settings and data for each pan so they don't all go to one display and sounds like you know how to do that. I am concerned about how to fit 8 pans on a display. I have 6500 so I don't think I can even create 8 of them. But for testing purposes I can double up some of the data and give it new data Id to make it look like additional pans. I have considered and probably will implement a "pan per window" option so ops of a 6700 could either try to cram them all into one window like my test or have each pan open in a brand new window and they can slide and size them as desired.

Walt - KZ1F

Actually, I believe you'll find the first pan is activated for you, as is the first one or more slices. This is part of the persistence, where the radio remembers what artifacts were active at the last shutdown. You will see this by watching the status msgs, on set for every radio object type, I.e., panadapter, slices, etc. If you shut down with one pan and 2 slices you'll restart with them.

Mark_WS7M

Walt,

That is the behavior I'm testing with most of the time.  I use SmartSDR to setup some pans/slices then exit, start my code and see how they look.

I have had a couple times were things were buggered up.  No matter what I set in SmartSDR when I'd exit and run my code I'd get some wacko pan with bizarre settings.

I restarted the radio and the problem went away.

Walt - KZ1F

Does that explanation your 3 pans? You created only 3 as the 4th already was created and you dropped it?

Walt - KZ1F

How much logging do you have cooked in? That'll be invaluable to understand what's happening.

Walt - KZ1F

I opened up a problem some time ago where I'd start ssdr and no pans were created. Worse, I couldn't manually create them either. I haven't seen that recently but I also haven't seen where FRS fixed it either. Nine others said they experienced that same phenomena. So, yeah, gremlins do appear. So, hopefully they did fix it, if only inadvertently. I'm thinking I'll release a free teaser version of XPSSDR in the next week or two. I figured I had all the time in the world to tear it down and rebuild it in a different image...right up until you started haunting my wheelhouse, :-)

Mark_WS7M

Walt,

The three pans in my video are three that I created in SmartSDR then exited.  As I explained to James, I know how to create and delete pans, I just am not doing it yet.  For my current testing I'm relying upon what is in the radio right now.

I have TONS of logging and level control for that logging.  In fact I have so much that if I enable it things get kind of boggy so I need to move the logging to a threaded queue.   I can log every single property sent back from the radio for all objects.  I can log the raw hex data for each packet including the vita UDP packets.

That's another thing I did... In looking at the vita49 implementation in FlexAPI I first modeled all of the classes but then realized they were mostly the same except for payload data.

So I've created just one vita49 packet class that maps the payload based on type into an array of data.  Then if it is a meter packet for example I have meter data extraction routines that look in the right places of the payload to gather the data.

I took this approach because I found myself copying data into a preamble, checking the preamble type then copying it again into the correct type.  With one packet type my code copies the raw data in, processes the header, then based on type from the header processes the raw data for the payload.

I realize this might break down if more vita types are added but it was significantly faster and I figure with my logging I can easily see if new packet types are available from a new firmware version.

LOL I have no intention to put anyone out of business. I'm having a ball with this and the challenge is fun.

Walt - KZ1F

I hope people reading this aren't too jaundiced to realize and appreciate humor. I added the wink so others would realize I was being light hearted.

I gave thought to doing that, subclassing Vita49 to form all the classes. What I will be doing just for grins and chuckles is writing a codec for the UDP packets. It was such a PITA to write them initially and the value to having a codec is marginal at best I just couldn't get all excited at the prospect. Frankly, by the time that occured to me I was pretty much into it. I did, however use a codec for the TCP streams. For those readers not understanding the significance of what I just said, unlike UDP, which is a datagram based protocol (a single packet is the message) TCP is a stream based protocol. There is no start of sentence end of sentence sent or received, it's a constant stream of bits. A command could take several packets. So the codec for TCP I use breaks that stream into discrete sentences such that ever onMessageRecv will always contain a completely formed response and always sends  a completely formed request. But good job on that Mark!

A comment Stu made 'within <some period of time> all software will be under a subscription model', I personally agree with. That is true for all the ISVs I've worked with over the last decade or more. As it relates to consumer market it is way easier to do that now than decades ago or even years ago. Apple provides an API to support it as does Google (IOS and Android). Where this is something else I'll have to design (everything else) I'll need to have the Apple and Google models just be strategy implementations for those and then write my own for Windows and Linux. This is why I mentioned teaser stripped down 'express' version for free. I don't want people to think, OK, great ... thanks, rather they have whetted appetites for the full bore implementation that'll grow over time and be under subscription, like log integration, embedded spots, shack integration (amp, tuner, rotor, remote, facsimile of DAX). There will be no such thing as nobody will want it...Minimally,  I will. If Tim is any judge (which he is) everyone on here knows my thoughts regarding the Microsoft consumer market software. Although, there seems to be some newbies here that might not...yet. ;-)

To your point though Mark, I agree. What I've been doing is (what is referred to as) iterative prototyping. I realize, for you, merely saying iterative prototyping would have sufficed but for others, likely, not so much.

Mark_WS7M

Hi Walt,

TCP is a love/hate thing for me.  I love it because of the speed and the fact that just about everything supports it and with the right info you can connect around the world.

I mean realistically there is no reason that my code could not connect to your radio and ask for pan/slice data.  The only issue I see is UDP.   While I know it works WAN wise, sometimes the common place routers (and some switches) are set to block them.  I also think some ISPs don't allow UDP.  So the answer there is VPN.

However on the hate site of TCP is exactly what you mention.  You only know when you have a complete message  when you get some character in your stream that you know is a end of message terminator.  For flex radio responses this seems to be a line feed.  So I wrote my TCP receiver to gather packets until a line feed then ship off that piece to be processed and clear the buffer for more incoming packets.

I have resisted sharing the code yet because due to the amount of working going into this I might want to put it up for sale.  But before any of you jump on me and scream bloody **** I want to point out that like in the movie "Jumper"... I'm different.

By this I mean I do realize that for most of us this is a hobby and I also think that a GUI/command control program for the FRS radios probably has a somewhat limited market.

So I'm considering subscriptions like you mention.  One thing I will guarantee to the community is the rates will be very very reasonable.  I am not doing this to make a fortune nor to replace my primary income.  The goal would be to cover the basic costs of supporting the product.

Perhaps there would be different subscription levels and maybe even a source code subscription.  I have not thought it through yet but I think these kinds of things make it worthwhile not only for me but for others that are interested.

Then again a change in my life might just make me post the code and say to **** with it.  One never knows these days.

I can say that I'm 59.  I feel like I have quite a few good years left.  In my "day job" I'm probably there until I reach 65... or at least I hope I'm there until then.  

I don't know the life time of the 6000 series radios but I hope they go for another 5+ years.  I could see this thing I'm working on being around and evolving over that period of time.

Walt - KZ1F

A very good friend of mine who I've known for over 30 years and was VP where I worked last got swept up in a layoff about a year ago and, to my knowledge, has not landed yet. He had been there like 30 years. I quit (retired) 4 months prior to that as I saw the demise of that whole collection of products doomed and the commute was awful, easily over 2 hours/ day. Right now I am trying to defer filing for SS. I'll be competitive with Stu and dogpark. Esp where mine will run anywhere even Android and one price likely will allow all flavors.

I don't perceive releasing my souce nor do I intend to create an open source project out of it. I would license the source that that would be at a commercial pricing structure.

I would suspect, once again insert disclaimer here, the 7000 series will follow the smartSDR model. I doubt it would be a new paradigm. I suspect our investment in time, BS&T will be secure. Well, OK, "I am not, nor have I ever been, affiliated with FlexRadioSystems or its parent company. I have no knowledge of their future plans".

Mark_WS7M

Walt, I will buy your product when it is released just to support you (assuming I can afford it and still have a job).  I bought Stu's, I bought dogpark too.

I agree on the source thing.  I do however thing licensing the source out makes sense in this situation because it is a hobby.  I would release the source of my product with the following disclaimer... 

You can't use my source to build a new product and compete with me.  If you want to use my source and develop a new product for sale then license that from me.

Any thing you modify, you are on your own to debug and support.  If you want my assistance it will cost something.  Sometimes just giving me your code so I can integrate it into the real product is enough.  Other times it might be monetary in nature.

Again all of this is hypothetical as I don't have anything worthwhile yet and if I do get to that point I'll have to see what interest there is.

Walt - KZ1F

In one sense I understand your intent there Mark, however. The copyright notice serves but a single purpose, it provides for a legal remedy IF you catch someone violating it. Suing someone for damages is not free and if/when you lose it is money out of pocket because lawyers NEVER lose. So someone could look at your disclaimer, nod politely and use it anyways, anyway they like.

Peter K1PGV

Here's my stance (in case anybody cares):

I don't release the source of anything I write. I don't believe in the FOSS philosophy.  I wrote it, I control it, that's the end of it.

When I write software for my own purposes that doesn't ****, I'm happy to release (executable versions of) that software for free to the public.  I release it for free because I don't want to be compelled to provide excellent support for it.  If I take somebody's money, I think they have a reasonable expectation of excellent support. I have to fix bugs on a timetable in my day job. I really have no interest in doing so for somebody who gave me lunch money a year ago.

I've done this with several things I've written over the years.  Works dandy.  I've fixed tons of bugs, people say thank you.  Or they don't.  But it doesn't matter.  Remember, I wrote the software primarily for my own purposes.

I would be very happy to release a free executable version my add-on for the 6000 series (it's called OpCenter) but.. guess what?  Some of the code happens to be based on GPL'ed software (for example, the digit-tunable display in PSDR).  Because the code is GPL'ed if I release my software, even for free, I have to release my source code.  And I'm not going to do that.  So, the community loses.  Because of the GPL.

Strange world, huh?  GPL isn't automagically a good thing.

Peter
K1PGV

Walt - KZ1F

I don't believe your last paragraph is entirely accurate. My understanding, and the way ISVs I've worked at worked, after passing all the hurdles of Corporate Legal, if the source of the GPL'd code isn't changed, you don't need to release the source code for it or your original work.Your original work, if you didn't apply GPL to it, isn't covered and if the code you used that was covered under it wasn't altered, your copy of that portion if the code need not be provided in source. If, however, you did modify the source of the gpl'd code only that code must be provided in source.

I didn't think anyone used GPL any longer. It is so 80s. Just to dot the i's, I never thought GPL was a good thing.

Mark_WS7M

@Walt - All good points.  While I try hard to own stuff I use probably I've violated something somewhere myself maybe even without knowing.  No need to tell me about lawyers... I know them all to well right now.

@Peter - Very good point.  I'll have to see when and a big if the time ever comes if releasing source makes any sense.

James Whiteway

Hmmmmm,,, I'll play! I have no problem paying for software. I well understand what it takes to bring a product to market.(yes, even thought I'm a truck driver, I have had enough experience with commercial software development to know what kind of effort even a small project can require) But, what I have been doing recently, is for my own learning experience. Not to create a saleable application. Plus, I do intend to openly share what I have, and hope to continue to, learn with others of a like mind. I did not get involved in this to make money. And from what I have seen so far, not even FRS is getting rich off software. Even when they do start charging for SSDR, they won't recover their costs from software sales. Hardware sales, most likely will bring in the needed bucks for them to carry on. The only reason I have not shared my panadapter code yet(with one exception) is not because I intend to sell anything, but it's because the code I have produced so far would make real developers like Walt, Mark, Peter, Stu and others cringe when they saw it! :-) And should someone with even less knowledge and skill were to try to use it in it's current form, they would become confused and might even learn some bad coding practices as well. OOP my current test software, is not. Well, it is but not lik it should be! But, I will share openly.with those that share an interest in learning the in's and out's of SDR software development and doing so with a Flex radio. No costs, no license agreements , just a chance to LEARN. After all, that is one of the reasons Amateur Radio exists. James WD5GWY

Mark_WS7M

Ok,

I spent the last few days implementing the waterfall and when I was done, CPU load was running about 35% which I consider to be unacceptable for any program to consume continuously.

So I ripped things apart, spent a fair amount of time looking at data flow and type of data and reorganized things a bit.  I now have the CPU usage running about 6.5% with fast moving waterfall displays.

My waterfall code has some minor issues that occur when you resize the window.  I'll be working to pull those in and fix them.  Also in this demo video the waterfall background and "white" level were set roughly to -120 for low, -53 for high.   Since my basic noise was above -120 I got a blueish hue to the background.   I have the ability to change the low/high values but no control to do so on this demo.

My slice display is very rudimentary so far. Just a line with a frequency and dBm/S meter text.  I plan to work on making a much nicer slice display.

Anyway here is the progress so far:

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

James Whiteway

Well done Mark! Wish my waterfall looked that good! Still struggling to get things flowing....... :-)

Ken - NM9P

To all the programmers in this thread...Thanks.

Although much of the finery is a little over my head as a "dabbler." (and some of it WAY over my head)  This whole thread has been fascinating for me.  I remember the excitement I had about a year ago merely learning how to use "Processing" and modifying some of William's code and writing some of my own new code to implement a DJ Controller as an interface for the 6500.  

William and I had some discussion similar to this, but at a much lower level of sophistication that matched my programming competence.  I think some of you even chimed in with some suggestions to help me begin to understand how to move from an old-style "linear" programming approach that I learned in the 70's & 80's with FORTRAN and BASIC to a more structured and object oriented programming format.  I am still miles away from anything I would call competent.  But I accomplished my goal of making it "useful."  Then I got involved in other aspects of the Flex radio game, and contesting grew, and my DJ controller project has stalled.  

Your thread has piqued my interest in taking up the Controller project again.
Perhaps I will one day learn C# and rewrite it in that language by myself.
Then I may learn how to do some of the things you all are doing.  
That would be quite a thrill to be able to say "I wrote this, and it works!" as I listen to and watch my 6500 on my own NM9P-SDR software! (But that is probably a LONG way off...(FRS will probably be marketing an 8000 series radio by then!)

Thanks for sharing your progress, fails, and philosophy about programming.  It is neat to see three or four programmers at least, with a little playful competition, all seeking the same goals of creating additional alternate software clients for different platforms.

Ken - NM9P

James Whiteway

Jump in Ken, the water's fine!

Ross - K9COX

If Then Else

Ken - NM9P

That, and lots of counters and compares, plus communications routines! For me it will require learning a new syntax and some new commands. Setting aside enough time to do it is going to be the challenge....

Ross - K9COX

At the time it made sense didn't it.