Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

Idiot's guides for comprehending CAT, DAX & DDUtil

KD3VK Ken
KD3VK Ken Member ✭✭
edited June 2020 in SmartSDR for Windows

I keep looking for any Idiot's guides to help comprehend CAT, DAX & DDUtil while trying to understand how they fit/work/help in the Flex 6x/SmartSDR world.  I finally stumbled across a diagram that started unraveling where DDUtil fits into the puzzle, and it also shed some light on the linkage or pairing of Comm ports that keeps surfacing.  This diagram appeared near the end of the KI5SS topic: https://community.flexradio.com/flexradio/topics/smartsdr-for-windows-smartsdr-cat-powersdr-flex-rad...

I tagged on to that thread asking for ideas where to be looking, but since the topic was more targeted to PowerSDR and the Flex1500 radio, I now realize I should start a separate thread to seek help on this in relation to SmartSDR and the Flex 6x radio environment.  I'll paste my original inquiry here to try to cast a more appropriate/targeted call for help:

============= My posting added to KI5SS thread ==============

Well, I almost blew over this thread because I thought it was only about power SDR in the earlier radios, and since I have a 6000 series using SmartSDR I thought there wasn't anything in it for me. Luckily I followed it further and see that the drawing by KD7YDW helped me a lot with my confusion about DDUtil and CAT.

I've been trying to follow all of the threads in the community just to get better a understanding as I get closer and closer to implementing a remote station. KD7YDW's drawing has been a big help to bring me around to the understanding that DDutil is just a software application that manages Comm ports in between the various additional support utilities that we use. Now I'm beginning to understand the reason for these parings of Comm ports, such as 3 and 13, 7 and 17, etc. I simply did not understand the what or why for DDUtil.

So, before I move on and start to try to figure out the same stuff about DAX functionality, I have a couple questions I hope someone could help me with.

First, even though his drawing is about PowerSDR, I want to verify that the basic functionality shown applies to SmartSDR as well? Are there any notable exceptions? It certainly was a big help in putting several of the pieces together in my mind.

Second, where is the 'idiot's guide' documentation that I have obviously missed explaining what, why and where for CAT & DDUtil. Because I often need a graphical diagram to understand some of these concepts, I will kick myself if there turns out to be a pre-existing drawing like this somewhere for CAT in SmartSDR. If so, I clearly missed it. (Before anyone flames me, yes I have tried to read the flex documentation for CAT. It's still just escapes me. Hence the desire for the idiots guide.) I realize the DDUtil is not a Flex product so I'm asking if anyone is aware of such an guide for it. I guess I'm also curious why, if such an important product or utility is needed, that it is not from Flex? Or did I miss something here?

I guess while I'm at it I'll also ask if there is something similar in the form of an idiot's guide for DAX? I try to follow all the dialogs on the DAX subject/problems. I've also tried to read the Flex documentation on the subject but it goes right over my head. So, since DAX seems to be such a complex subject, if there is some document & diagram that ties it all together at a high level for DAX too, I sure want to find it.

Thanks for any help or directions any of you can give me. 73

Answers

  • Terry K8EET
    Terry K8EET Member ✭✭
    edited February 2019
    Ken, After reading your post and saying amen a couple times, I started doing a little research. (commonly referred to as Googleing) This link may be of some help.  It's on my reading list for tomorrow.  http://www.dxlabsuite.com/dxlabwiki/FlexSignature
  • Barry Meltzer
    Barry Meltzer Member
    edited February 2016
    Goooooooooood Post Terry, Tx     Barry, K3MY
  • G4NRT
    G4NRT Member ✭✭
    edited December 2016
    I am not sure whether I need this or not but I have bookmarked it in any case .. Thank you!  David G4NRT
  • KD3VK Ken
    KD3VK Ken Member ✭✭
    edited December 2016

    Terry K8ET,

    Wanted to reply off-line but can't see how.  Anyway, thanks for the link, however I'm not sure if it is what I am looking for...  It looks like a nice wiki site with some good information on configuring for the various digital apps. etc.   Good information to bookmark for when I am ready to set them up, but I'm looking for some really basic info on 'what are CAT, DAX & DDUtil, when do I need them, and why' stuff.  As I mentioned earlier the diagram helped show where DDUtil fits in between the 3rd party apps, and how the pairs of Comm ports relate between the links. 

    But at a more basic level, what if I don't use the DDUtil tool?  So, if Flex provides the ability to communicate via CAT to outside apps, are there other ways to do it if DDUtil didn't exist?  Is DDUtil the only way to deal with the many outside tools/apps we use to make our radio dance?  Logging, skimmer, cluster automation, etc. for example.

    I don't get the situation where a 3rd party tool (DDUtil) is needed to allow me to link/intercoonect multiple apps with the SmartSDR program.  Why isn't the capability inherent in SmartSDR without needing someone else's add in/on tool?  Or is it just a stop-gap solution until Flex plops a solution from the sky?  I realize I am trying to look behind the curtain, but I don't want to waste a lot of time getting proficient at something that there is a better solution for here now, or coming.

    I think I am trying to find a 'Primer' for:  "Here's the tools you need in your toolkit to do RITTY/Packet/DX Cluster/DV/etc. with your radio", or "Here's a diagram of how (and where) DAX fits into the picture", or a "Here is a summary of all those 3rd party apps that can either control your rig besides SmartSDR, or apps that help you do these xyz modes". 

    For example, simply put, DAX confuses the **** out of me because of all the interrelated (and competing?) connections that are required to just get the audio from or to the right place where I need it to accomplish something! 

    (I won't even mention how confused I am already at trying to figure out the 'goes into/goes outa' connections on the back of the Flex6700 to get my planned transverters running for 2M and 440  to be able to do satellite work on one radio. That's a whole 'nother ball game!)

    I am obviously missing something at a beginners level that is preventing me to sort out all these varying complex tools that are being discussed on the Flex Community.

    I need to go back to start and have a Kindergarten teacher or primer to help me!  Haven't yet found a 'savvy' SmartSDR user in the San Antonio area to take to coffee and pick their brain.  So for now I need to try to keep up with all the posts on the community just to build a list of all that stuff  'I need to learn'.

    But, thanks for any links or guidance suggestions to help me 'reset'.


  • Terry K8EET
    Terry K8EET Member ✭✭
    edited July 2016
    Ken, 

    You definitely do not need fldigi (thank goodness) to use (most) logging programs.  For starters the easiest way to use CW Skimmer is to download SDR Bridge. For me, the easiest logging program to setup with CW  is N1MM. However, this is a logging program for contesting. If you're looking for a general logging program that is easy to setup, I would suggest looking at Log4OM, it connects to the Flex for frequency and mode inputs, and has a good spotting/cluster interface. This is best setup with Omni-Rig. (Rig Type TS-2000, Baud Rate 4800) All of these programs have a place to setup ports to be used.

    There are pretty good you tube videos for setting up these programs. 

    This is my understanding of setting up ports.  If you enable a port in the new CAT control like Serial COM4 it will create the required port COM107 in Windows automatically. You can verify this by going to the Windows Control Panel and selecting Device Manager and then selecting Ports (Com & LPT) You will see all of the ports that have been enabled there.

    As Paul Harvey used to say, "I've told you more than I know." I hope all of this is accurate and not so basic to insult anyone's intelligence.

    You can find my email on QRZ.Com 
  • KD3VK Ken
    KD3VK Ken Member ✭✭
    edited December 2016

    Howard,

    As always, you offered an eloquent and understandable explanation for Lesson 1!  Thank you. 

    I have some past experience since the 70's in what you hit on with the competing CAT interfaces/protocols/level translators (Yaesu, Kenwood & Icom) and your explanation brought me back to that era in history, and since. 

    So my takeaway from this is that we are still in a transition phase between the 90's mix of CAT implementations and the future IP methods.  Further, the need for hardware connections between devices/applications is quickly disappearing in favor of virtual or pseudo ports in or between software applications.   

    Your encouraging comments about Ethernet replacing all this is in line with my feelings/plan to be ready for more, or a total move to, IP interfacing of my station accessories and applications.  I'm guessing we will still have the continual growth (improvements maybe?) in the various CAT command lists for some time yet, until one of them becomes the dominant one everyone gets onboard with?  Realizing of course that we will never be able to anticipate what new needs/commands will come tomorrow and need to be added.

    I am anxiously following the 4O3A product development/releases (and Flex's intended collaboration) before I invest in any more interface hardware, but I realize we will probably be faced with needing DDUtil or the like for the glue necessary to keep today's breed of H/W & S/W working well together for the foreseeable future.

    I think I am on target in these assessments?

    I am very anxious to see Lesson2 from you!  But, while even more excited to see your Lession3, from what I comprehend up to now on the (ever moving) Flex DAX implementation, I fear you have bitten off more than you can chew on that offer!  But please don't let me discourage you.

    Thanks for your help.  I read every one of you posts with great interest, even if it isn't about something I understand or feel I will encounter.

    73

  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited February 2016
    @Ken

    Congratulations.. You just got a passing grade on Lesson 1...

    Things are ever changing.. and it really is a huge messy CAT world out there

    Yes.. we need something like DDUTIL for the foreseeable future to act as the glue to hold it all together (translating the different peripheral protocals, CAT Command Sets and physical interfaces) until the ham world agrees on a common standard which one hope will be IP based...

    Flex and 4O3A have made major advances in pulling it together under Ethernet IP .. We can only hope the rest follow suit ... the big Elephant in the room is the Japanese vendors who have been very protective of their obsolete standards and very slow to adopt IP technology...

    Currently playing with Maestro while crawling under the BBQ for the last 3 days to try to cap a leaky pipe in a virtually inaccessible location... the price of water in SOCAL is much higher the the price of power..


    If I ever cap that leak successfully and redirect the pipes.. I will get to new lessons...
  • Bob - W7KWS -
    Bob - W7KWS - Member ✭✭
    edited February 2018
    And so...except for DDUTIL, which is a language translator, all of the other items mentioned, including Ethernet, are just physical or in the case of virtual ports, pseudo physical transport means. 

    The language translator (DDUTIL or other) is essential as none of these manufacturer's languages remain able to talk to one another and so little has been gained along the road from RS-232 to USB outside of availability and transmission efficiency.  Even Ethernet is no help except that it provides capacity for things like spectrum images and ease of wide area networking but still no help with a common language among different manufacturers' equipment.  It seems that, for the foreseeable future, a PC remains central to the equation.
  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited January 2017
    True except DDUTIL not only translates language but it allows different physical transport mechanisms to talk to each other.
  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited February 2019
    Lesson #3 DAX

    DAX means Digital Audio Exchange.  But more on that later.

    Ham Radio originally started with CW (actually Spark Gap) and then progressed to Voice. (AM, SSB and FM).  However in the commercial world there as a need to transfer written text at speeds higher than CW speeds and with high degrees of accuracy. 

    Skilled CW operators were hard to find so where there was a need there was a solution.. The first solution was to develop landline teletype machines which quickly morphed into Radio Teletype Machines There was also a need to send pictures so we developed facsimile machines and other visible mechanisms like Hellschreiber..

    How do these mechanical marvels send test over the air.. they mechanically and later electronically converted text into symbols which in turn were encoded with sounds so that they could be sent over the radio.    From about the 1930's hams were sending Radio Teletype Messages (RTTY) all over the world.  .. you did not need to be a skilled CW to send text quickly and accurately.

    So where does the word DIGiTAL come in...CW is really a digital mode.. it consists of Dits, Dahs and spaces... Every alphabetic character is represented by a series of symbols (Dits Dahs).  The is true for RTTY except the coding is more complex ( 5 Level code  representing each character consisting of up to 5 Marks and Spaces) and it uses 2 tones or frequencies rather than one like in CW.  So to send RTTY you need to be able to quickly change the sending frequency to represent the correct sequence of marks and space tones.  

    For years this was accomplished by adding physical interfaces to your radio so that your keyboard could change the frequencies.   These devices are called Terminal Network Controllers (TNC).  Over the years TNC got more computing power so that eventually all you needed to do was send text to the device and receive text from the device as the device did all the heavy lifting inside it.

    Starting in the 1980's with the advent of Personal Computers, innovative hams started to use the computer's sound card to generate the needed tones to modulate and eventually decode RTTY signals.   of course, there was a problem in that Audio tones from a computer do not easily match into a radio's microphone nor does the receive tones from the radio match into the Computer's microphone input.

    This ultimately lead to the development of the Sound Card Interface which which is simply a device to match radio and computer sound cards together.

    By about 2000 you had two competing technologies.. TNC - an external box to do the data translation for you and Sound Card Interfaces - an external box to match the radio to the sound card.  As computers became more powerful and cheaper.. it became obvious that for most ham requirements the Sound Card Interface was a better solution.  Plus the increasing processing power led to the advent of new modes like PSK, PACTOR,JT-65 with very significant advantages over RTTY. and CWSkimmer to replace human operator  While adding these features to a TNC usually meant buying a new device - for a sound card interface it only meant adding new software to encode and decode.

    With the advent of the SDR, it seemed to be rather redundant to decode a digital signal to analog audio output send it to a computer analog sound card input so that it could be digitized and decoded when the sound was already in digital format inside that computer.. Plus the decoding into analog sound and encoding that analog sound back into digital form adds noise and distortion to the signal causing degradation of the digital processing. 

    About 2005 Hams with SDR's started to keep the sound entirely in digital format inside the computer..   BUT.. it's 2005.. the Ham Computer Programs such as CWSkimmer, PSK, HRD, WSJT all were designed for physical Sound Card Interfaces.  Hence there was a need to create a Virtual Audio Cable to pretend to be a sound card interface to the digital computer programs. As far as the computer programs were concerned they were still dealing with computer sound cards even though now the entire signal stayed in digital form inside the computer.

    There were many Virtual audio cables on the market.  None were written specifically for ham radio needs but they worked OK with limitations.  They were relatively complicated to set up and easily confused the beginners.  Some worked better than others with different programs...By about 2012 there were a heck of a lot of support questions about interfacing the different virtual audio cables...

    FLEX had a better idea for the 6000 series.

    They created their own Virtual Audio Cable(VAC)  and called it Digital Audio Exchange (DAX).  DAX is much more powerful than most VAC as it has specific channels assignable to each radio receiver slice.  PLUS DAX can handle very large data streams up to 192KHz in bandwidth compared to the usual VAC Maximum of 48KHz.

    DAX has been designed specifically for Ham Radio Needs.. it provides an easy to use Virtual Sound Card interface from any specific radio receiver slice to any Digital Data program that can accept a sound card input.   Very simply it replaces the computer sound card and the noise and distortion of an external sound card interface so that you get the best possible decoding and encoding of your digital data.

    For more information you might want to read my
    "Modern Radio - SDR 101"  https://db.tt/0ALtyaj9


    I think i am done here ... my pipe is still leaking - so back under the BBQ tomorrow.

    Please post questions that need clarification...
  • DrTeeth
    DrTeeth Member ✭✭
    edited August 2016
    Howard, many thanks for the lessons. All copied and saved for my 'library'.
  • Ken - NM9P
    Ken - NM9P Member ✭✭✭
    edited June 2020
    Very nice articles, Howard!  Thanks.

    One step in the middle between TNC & Sound Card interface lasted a very few years.
    It was the "slicer" made of a 741 IC that sensed the zero crossing voltage swing of an audio signal and sliced it into ones and zeros for an RS232 port.  There were a few programs, one was called JVFAX, I think, that was able to decode FAX and SSTV from the slicer interface.  Transmit audio output was crude, either holding the mike up to the computer's internal speaker, or by tapping into the audio line.  Switching was either manual PTT or VOX.  My radio club in Paoli, Indiana used this in the early & mid 90's to send SSTV on 2 meter FM until sound card interfaces became popular for SSTV, RTTY & Packet, etc.  Those were days of fun experimentation!

    Ken - NM9P

  • KD3VK Ken
    KD3VK Ken Member ✭✭
    edited December 2016

    Howard,

    I see I never got back and thanked you for all the great info.  THANKS!

    I hope your pipe leak is fixed by now.  Can't offer much assistance from TX, but I sure would if I could.  I hope some of the CA folks would offer to help you with such problems and allow you more time to publish additional 'Idiot's Guides' for those of us that need them with these wonderful but complex products.  FRS needs your help in this endeavor while they are busy finishing our Maestro units!  :-)  I hope to have an eyeball QSO with you and Ken-NM9P at the Flex Banquet in Dayton to thank you both personally for all the tutoring help to the Flex Community. 73

  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited February 2016
    Leak was finally found and fixed. Here is a link to all the idiots in one place https://www.dropbox.com/s/10lw1wo5m6s0s2x/Idiots-Beginners Guide to Flex Radios.pdf?dl=0 C U at Dayton
  • G4NRT
    G4NRT Member ✭✭
    edited December 2016
    Thank you Howard! Saved to my Dropbox for future reference! David G4NRT
  • DrTeeth
    DrTeeth Member ✭✭
    edited August 2016
    Thanks Howard, also saved to my local 'library'. I wonder if you could consider a more advanced article on DDUtil? Personally, I would find it useful, especially as your writing style makes the complicated as easy as possible to understand.
  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited February 2016
    It's on my list
  • Walt - KZ1F
    Walt - KZ1F Member ✭✭
    edited November 2016
    Good description Howard! However, my concern is USB will replace rs232, not TCP and Ethernet.
  • Walt - KZ1F
    Walt - KZ1F Member ✭✭
    edited November 2016
    Good writeup Howard! My concern is Ethernet will not replace rs232, USB will. Witness mfj and dcu-3. The other problem with Ethernet is it is an involved software protocol requiring a minimum of IP translation, UDP translation, and TCP translation, plus all the routing, be it rip or ospf, etc.
  • k3Tim
    k3Tim Member ✭✭✭
    edited December 2016
    I had not heard of this method. Having the PC time the zero crossings (back then) must have been challenging. 
    My favorite (homebuilt) TU was based on the LM 565 PLL. It seemed to be able to follow the signals into the noise and decode them, in addition to frequency tracking. Very handy when using an Eico 753 for RTTY..

    The good old days - not so much.

    k3Tim
  • KY6LA_Howard
    KY6LA_Howard Member ✭✭✭
    edited February 2016
    You can rely on ham radio companies sticking with old obsolete technology as long as possible in order to protect their sunk development costs. Since USB implies minimal software change it will be around longer than it should be. The rest of the world is Ethernet
  • Walt - KZ1F
    Walt - KZ1F Member ✭✭
    edited November 2016
    Yes, you mentioned that before, both privately and publicly. I believe you are correct. In fact, though, I suspect a full TCP/IP stack could be burned into a relatively small eprom plus the logic to read the requests and reply with responses. It's just that is more 'expensive' than a usb facsimile to rs-232. I've already wired in KAT-500 KPA-500 into my software with an interface that could model the implementation to other tuners and amps. As I don't have other tuners and amps I can not write their concrete logic.

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.