Again!
I heard today that my Flex 6500 has been fixed and will be on its way back home next week. That's great news and I am looking forward to cracking on with operational evaluation, aka making QSOs.
I've not been completely idle in the past week. Apart from making full use of the nice weather by getting lots of flying in, I have also added significantly to my Windows API code. As I now expect this to form the basis of the Mark II controller, there is quite a lot of additional functionality to implement. It'll be several more months before I can start work on the Mk II controller in earnest as I have decided that the hardware platform will be the Udoo X86 and I won't get my first sample until December.
Hopefully I shall have the 6500 back before the end of the week and I will write more then.
27 August 2016
15 August 2016
D'oh!
Back in April my Flex 6500 developed a rather odd fault which resulted in the radio being very deaf on 21/24/28MHz. This turned out to be a fault in the front end amateur radio band filter switching - when I set the radio to "Wide", i.e. taking in more spectrum than the amateur band, it was OK. Away the radio went for a vacation in Germany (the European Flex repair facility) and when it returned from its sojourn all seemed to be well.
Last week the fault returned. I suppose, in reality, that it was there all the time (perhaps intermittently) but as I was busy writing software rather than using the radio for making QSOs, I just assumed that the bands were a bit on the dead side. Anyway, the fault seems to be "hard" and, to give FlexRadio and the UK distributor their due, they have acted very quickly to sort it out.
So my software test-bed goes away to Germany again tomorrow and I have another couple of weeks of limited development capability. All is not lost - I can still work on parts of the code that don't directly interact with the radio. And, to be honest, I really ought to be making a start on my presentation for the RSGB Convention in a couple of months' time.
Hopefully when my 6500 comes back from DL it will be 100%, as is the general reputation for these radios. Meanwhile, updates to this Blog may be a little less frequent. I'm off now to make a few more QSOs before I have to pack it in its shipping box.
Last week the fault returned. I suppose, in reality, that it was there all the time (perhaps intermittently) but as I was busy writing software rather than using the radio for making QSOs, I just assumed that the bands were a bit on the dead side. Anyway, the fault seems to be "hard" and, to give FlexRadio and the UK distributor their due, they have acted very quickly to sort it out.
So my software test-bed goes away to Germany again tomorrow and I have another couple of weeks of limited development capability. All is not lost - I can still work on parts of the code that don't directly interact with the radio. And, to be honest, I really ought to be making a start on my presentation for the RSGB Convention in a couple of months' time.
Hopefully when my 6500 comes back from DL it will be 100%, as is the general reputation for these radios. Meanwhile, updates to this Blog may be a little less frequent. I'm off now to make a few more QSOs before I have to pack it in its shipping box.
14 August 2016
Operational evaluation
"No battle plan survives contact with the enemy" - Helmuth von Moltke
So, it seems, it is with homebrew FlexRadio controllers! After almost a week of hands on operation, in which I've made a good number of DX QSOs and a bunch of contest QSOs in WAE, I can expand on this basic premise in the Flex controller context as follows:
So to my mind, the concept is validated. There are no show stoppers. Yes there are improvements that can and indeed must be made but, hey! it's software - we can do this.
I think the biggest issue is also the controller's biggest asset - its sheer flexibility. Since any physical control can be assigned any function, it follows that there is no fixed relationship between control position on the panel and its function. Thus, there is no point in labelling the control - it is whatever we want it to be. But this carries its own set of problems: "what is that control doing right now?" Or from another perspective, "where is the control to do ...?"
Exacerbating this issue is that the encoders have four discrete functions, arranged in two pairs. One such control is the volume control for VFO-A. The shifted function is audio pan - well at least you'll soon work out what's going on if that's selected instead of audio gain. However the second pair, as currently configured is TX power and tune power. I have lost track of the number of times I have tried to adjust the audio level, only to find the control wasn't doing that - it was winding the Tx power up and down!
Well, that can be fixed in a number of ways. The obvious approach is to avoid silly control combinations like that! I also think that I'll try a time-out for the second function pair, perhaps 10 seconds, so the control always returns to the primary function set automatically.
Anyway, I have a little list and I shall be working through that over the next week or so.
The next point is more fundamental. For all that we have blindingly fast networking and unlimited processing power these days, the fact remains that it takes a finite amount of time to move commands and data across the network and then process them. This is most noticeable with VFO tuning, where if you tune quickly then the radio misses a few steps in an attempt to keep up. This has the effect of sounding like the step has changed and instead of the CW note varying smoothly as the dial is turned, instead it moves in distinct steps. A bit like the very early synthesiser radios.
It's not clear to me yet whether this is a network speed issue or a processing limitation... or perhaps both. It's not terribly important but when one has been used to a nice radio like the FT5000, it feels like a bit of a step backwards.
And that brings me neatly onto the last point. Processing power. I'm increasingly coming to the conclusion that the Arduino Due (the most powerful in the Arduino range) is just not quite powerful enough for this application. I see this in various ways: the VFO tuning issue I mentioned above, a tendency for the display to get behind and start showing gibberish, slow response to the more complex rotary encoder functions and so on.
I'm not saying that the current set up is inadequate but I just have a feeling that I need more power. The only way to find out will be to try something bigger and as I have discussed on several occasions, the Udoo X86 processor seems to be an ideal test bed. As I'll not be able to get my hands on one until December, I have plenty of time to continue making improvements to the Mk I controller!
Anyway, this has been a most excellent and useful exercise. I plan to continue with a mixture of software development and hands on QSO-making and see where that gets me to.
So, it seems, it is with homebrew FlexRadio controllers! After almost a week of hands on operation, in which I've made a good number of DX QSOs and a bunch of contest QSOs in WAE, I can expand on this basic premise in the Flex controller context as follows:
- For the most part the controller works well
- There are numerous minor tweaks that will make it work much better
- There are clear limitations in a network controlled radio that are either not apparent in traditional radios or, at least, are much less pronounced
- There are performance issues that seem to indicate that a Mk II controller with a more powerful processor will be needed sooner or later
So to my mind, the concept is validated. There are no show stoppers. Yes there are improvements that can and indeed must be made but, hey! it's software - we can do this.
I think the biggest issue is also the controller's biggest asset - its sheer flexibility. Since any physical control can be assigned any function, it follows that there is no fixed relationship between control position on the panel and its function. Thus, there is no point in labelling the control - it is whatever we want it to be. But this carries its own set of problems: "what is that control doing right now?" Or from another perspective, "where is the control to do ...?"
Exacerbating this issue is that the encoders have four discrete functions, arranged in two pairs. One such control is the volume control for VFO-A. The shifted function is audio pan - well at least you'll soon work out what's going on if that's selected instead of audio gain. However the second pair, as currently configured is TX power and tune power. I have lost track of the number of times I have tried to adjust the audio level, only to find the control wasn't doing that - it was winding the Tx power up and down!
Well, that can be fixed in a number of ways. The obvious approach is to avoid silly control combinations like that! I also think that I'll try a time-out for the second function pair, perhaps 10 seconds, so the control always returns to the primary function set automatically.
Anyway, I have a little list and I shall be working through that over the next week or so.
The next point is more fundamental. For all that we have blindingly fast networking and unlimited processing power these days, the fact remains that it takes a finite amount of time to move commands and data across the network and then process them. This is most noticeable with VFO tuning, where if you tune quickly then the radio misses a few steps in an attempt to keep up. This has the effect of sounding like the step has changed and instead of the CW note varying smoothly as the dial is turned, instead it moves in distinct steps. A bit like the very early synthesiser radios.
It's not clear to me yet whether this is a network speed issue or a processing limitation... or perhaps both. It's not terribly important but when one has been used to a nice radio like the FT5000, it feels like a bit of a step backwards.
And that brings me neatly onto the last point. Processing power. I'm increasingly coming to the conclusion that the Arduino Due (the most powerful in the Arduino range) is just not quite powerful enough for this application. I see this in various ways: the VFO tuning issue I mentioned above, a tendency for the display to get behind and start showing gibberish, slow response to the more complex rotary encoder functions and so on.
I'm not saying that the current set up is inadequate but I just have a feeling that I need more power. The only way to find out will be to try something bigger and as I have discussed on several occasions, the Udoo X86 processor seems to be an ideal test bed. As I'll not be able to get my hands on one until December, I have plenty of time to continue making improvements to the Mk I controller!
Anyway, this has been a most excellent and useful exercise. I plan to continue with a mixture of software development and hands on QSO-making and see where that gets me to.
8 August 2016
Integration III
Today is a red letter day! My controller has moved 8ft to the right along my desk. Not in itself a big deal but in so doing it has also moved out of my software development lab and into my operational station. And that is a big deal!
Firstly I had to make up a bunch of cables. Suddenly I need two more Ethernet cables up that end of the room and, of course there's all the usual stuff to connect the Flex 6000 in with the rest of the shack. I'm rather pleased that I was able to simply parallel up the FT5000 and Flex radio audio outputs, so I can swap between them with ease and QSOs on both rigs will be properly recorded by StarLog. The Tx enable on my KPA500 linear similarly seems to be quite happy to be paralleled up.
Of course it wasn't all plain sailing. I found that StarLog would happily work with either the Flex 6000 or with the FT5000 but not both. A few coding tweaks and that was resolved. I also chickened out of trying to use a single paddle for both rigs, so I've brought my old Bencher out of retirement to be the paddles for the Flex rig. Depending on how things go the MagPad and the Bencher may get swapped around before too long!
So this is an important day. I shall now be able to start using my controller for making QSOs. I'm quite sure this will yield all manner of ideas for improvements. You'll get to hear about it here. Now I am off to play radio!
 |
| The G3WGV Flex Controller is on the left, FT5000 centre stage and logging PC on the right. Lurking in the background the KPA500 is just visible |
 |
| Close up of the two contenders. Which one will win? |
Of course it wasn't all plain sailing. I found that StarLog would happily work with either the Flex 6000 or with the FT5000 but not both. A few coding tweaks and that was resolved. I also chickened out of trying to use a single paddle for both rigs, so I've brought my old Bencher out of retirement to be the paddles for the Flex rig. Depending on how things go the MagPad and the Bencher may get swapped around before too long!
So this is an important day. I shall now be able to start using my controller for making QSOs. I'm quite sure this will yield all manner of ideas for improvements. You'll get to hear about it here. Now I am off to play radio!
7 August 2016
Integration II
The past few days have seen more progress on integrating the FlexRadio system into my station. I've now completed the integration with my logging program StarLog and all the numerous radio control functions are working as far as I can tell. Of course the proof of this will be actual use - there is only so much testing that one can do, it has to be used live.
I've started thinking about documentation and, notably, my upcoming presentation at the RSGB convention in October. It occurred to me that the overall architecture will be conceptually new to many people, so that's a good place to start.
A fundamental concept is that the Flex 6000 can support multiple clients. In my case I have three:
Between the FlexRadio and each of the user clients there is an Application Programming Interface (API). These serve as an interface, driving the radio protocol on one side and providing data in a structured fashion to the application. Somewhat similar to the familiar concept of device drivers.
Each of these API/application pairs can reside in a separate physical computer, or, indeed, be run together on a single platform... within reason. The SSDR application, in particular is fairly resource intensive and requires a fast PC. StarLog is another substantial Windows-based application. Conversely, the Mk 1 G3WGV Controller runs on a lowly Arduino.
Which brings us neatly on to what computing platforms to use operationally. At the moment my station logging program runs on a 2009 vintage laptop, which is just about adequate for the task but quite certainly will not be able to take on running SSDR as well. I like using laptops for logging because the computer is on 24x7. Laptops have relatively low power consumption and also have a battery to tide over any power outages.
One solution may be to simply get a more recent and thus more powerful laptop. However, I am now looking into a more bespoke solution using a relatively new "maker board" the Udoo X86.
This is a most interesting new board. It is a powerful Quad Core Intel X86 system that will run Windows and support multiple full HD screens, etc. It should be easily able to run StarLog and may also be able to run SSDR concurrently. But more interesting even than that is that it has a built in Arduino compatible processor.
Why is this interesting? StarLog, amongst other things provides control of antenna selection via four digital I/O pins that send a 1 of 16 antenna selector signal to an antenna switch at the base of my tower. This means that I never have to select an antenna, nor do I have piles of coaxial lines running back to the shack and manual coax switches. Just a single LDF-450 cable. Handy!
At the moment I deliver this via a USB to parallel port interface unit. It works but it is rather untidy and is a bit of a challenge to get working after a computer restart. With The Udoo it would be simplicity itself to code this into the Arduino section and have a single board unified solution.
I also have a MicroHam microKeyer 2, which while it is a nice piece of kit, for me it serves only to be a WinKey keyer and an easy way to interface audio into StarLog's QSO recorder. Long ago I wrote an Arduino WinKey emulator that could run on the Udoo and with with the Flex system there is no longer the same issue with audio sources, so I could manage without the microKeyer.
I don't yet know whether I could also run SSDR on the same Udoo board. There's no problem from a connectivity point of view, it's mainly going to be about processing power. Also in the TBA category is whether I could run a "Mark 2" G3WGV controller on this set-up. Here the issue is connectivity - I need lots of I/O pins to support the encoders, switches, etc. The Udoo is rather short of these compared to the Arduino Due. A solution using multiplexing might be feasible... another thing to look into.
Anyway, however it works out, the Udoo board is definitely worth investigating and I have one on order. The only trouble is that it won't be available until December. Looks like a winter project to me!
I've started thinking about documentation and, notably, my upcoming presentation at the RSGB convention in October. It occurred to me that the overall architecture will be conceptually new to many people, so that's a good place to start.
- Smart SDR (SSDR), which provides the graphical interface - waterfall, pan adapter, etc.
- G3WGV Controller, which provides the physical user interface
- StarLog, which is the logging program interface.
Between the FlexRadio and each of the user clients there is an Application Programming Interface (API). These serve as an interface, driving the radio protocol on one side and providing data in a structured fashion to the application. Somewhat similar to the familiar concept of device drivers.
Each of these API/application pairs can reside in a separate physical computer, or, indeed, be run together on a single platform... within reason. The SSDR application, in particular is fairly resource intensive and requires a fast PC. StarLog is another substantial Windows-based application. Conversely, the Mk 1 G3WGV Controller runs on a lowly Arduino.
Which brings us neatly on to what computing platforms to use operationally. At the moment my station logging program runs on a 2009 vintage laptop, which is just about adequate for the task but quite certainly will not be able to take on running SSDR as well. I like using laptops for logging because the computer is on 24x7. Laptops have relatively low power consumption and also have a battery to tide over any power outages.
One solution may be to simply get a more recent and thus more powerful laptop. However, I am now looking into a more bespoke solution using a relatively new "maker board" the Udoo X86.
Why is this interesting? StarLog, amongst other things provides control of antenna selection via four digital I/O pins that send a 1 of 16 antenna selector signal to an antenna switch at the base of my tower. This means that I never have to select an antenna, nor do I have piles of coaxial lines running back to the shack and manual coax switches. Just a single LDF-450 cable. Handy!
At the moment I deliver this via a USB to parallel port interface unit. It works but it is rather untidy and is a bit of a challenge to get working after a computer restart. With The Udoo it would be simplicity itself to code this into the Arduino section and have a single board unified solution.
I also have a MicroHam microKeyer 2, which while it is a nice piece of kit, for me it serves only to be a WinKey keyer and an easy way to interface audio into StarLog's QSO recorder. Long ago I wrote an Arduino WinKey emulator that could run on the Udoo and with with the Flex system there is no longer the same issue with audio sources, so I could manage without the microKeyer.
I don't yet know whether I could also run SSDR on the same Udoo board. There's no problem from a connectivity point of view, it's mainly going to be about processing power. Also in the TBA category is whether I could run a "Mark 2" G3WGV controller on this set-up. Here the issue is connectivity - I need lots of I/O pins to support the encoders, switches, etc. The Udoo is rather short of these compared to the Arduino Due. A solution using multiplexing might be feasible... another thing to look into.
Anyway, however it works out, the Udoo board is definitely worth investigating and I have one on order. The only trouble is that it won't be available until December. Looks like a winter project to me!
3 August 2016
Integration I
For all that it's fun developing cunning software and building controller hardware, ultimately the goal is to integrate the Flex rig into my station, perhaps replacing the FT5000 that has done the job very well for the past few years. So my attention has been focussed in this area recently.
In an earlier posting I discussed the Windows API that I have been writing. This has got to the point where it can be integrated into my logging program, StarLog, so I've spent a gratifyingly small amount of time doing that. The logger can now read and correctly interpret slice frequencies and mode.
My next challenge is to send frequency/mode information to the radio and manage slice creation/removal to facilitate split operation. This is important because, for example, with the FT5000 I can click on a spot that shows "Up 2" or whatever and that automatically sets the Rx frequency, enables the sub VFO, sets it as the Tx VFO and sets its frequency to the correct split. StarLog also has useful short cuts like Ctrl-U to set a split up, Ctrl-D to set split down and Ctrl-S to set simplex operation. All this should be possible with the Flex... I just have to write the code.
Another integration challenge is QSO recording. The Flex SSDR includes a separate client known as DAX that streams slice audio as a sound device. This sounds just the job but it turns out to not quite be what we need.
With the FT5000 I record a stereo audio channel. If I'm running simplex then both left and right carry the same audio - the main Rx. When I select split, the main Rx (DX) goes the the left channel and the sub Rx (pileup) goes to the right channel. Side tone is on both channels regardless of split mode. This works well and is perfect for listening to recordings after the event.
The Flex DAX has other ideas. Each slice (VFO in common parlance) creates a separate mono audio channel. There is no way to merge two slice audio channels into a single stereo channel. I might be able to take two mono channels and merge them into stereo in StarLog but it's far from ideal because the simplex audio would only go to the left channel. Not a show stopper though.
Worse is that the DAX streams do not carry side tone. Indeed there is no DAX channel for side tone. As a 100% CW operator that is a show stopper - I would only be recording one side of the QSO. Come to that, the same applies on phone and probably on data modes. I can't find a solution to this problem, although I am making enquiries on the FlexRadio forum.
If, as seems highly likely, I am unable to use DAX for QSO recording I shall have to use one of the two analogue audio outputs. The Flex has separate headphone and low level speaker outputs, each with their own level controls. Both are more or less the same output level. I traditionally have headphones and speaker connected in parallel (donning the cans when the going gets tough, turning down the speakers if necessary). So I could use the loudspeaker output for that function and the headphones output, via the PC sound card, for recording.
That'll work but I had rather hoped to get away from wires given that the audio is already digitised and available in the PC to support SSDR.
At this rate it won't be too long before I can make the Flex 6500 my station radio. Just in time for the sunspots to disappear!
In an earlier posting I discussed the Windows API that I have been writing. This has got to the point where it can be integrated into my logging program, StarLog, so I've spent a gratifyingly small amount of time doing that. The logger can now read and correctly interpret slice frequencies and mode.
My next challenge is to send frequency/mode information to the radio and manage slice creation/removal to facilitate split operation. This is important because, for example, with the FT5000 I can click on a spot that shows "Up 2" or whatever and that automatically sets the Rx frequency, enables the sub VFO, sets it as the Tx VFO and sets its frequency to the correct split. StarLog also has useful short cuts like Ctrl-U to set a split up, Ctrl-D to set split down and Ctrl-S to set simplex operation. All this should be possible with the Flex... I just have to write the code.
Another integration challenge is QSO recording. The Flex SSDR includes a separate client known as DAX that streams slice audio as a sound device. This sounds just the job but it turns out to not quite be what we need.
With the FT5000 I record a stereo audio channel. If I'm running simplex then both left and right carry the same audio - the main Rx. When I select split, the main Rx (DX) goes the the left channel and the sub Rx (pileup) goes to the right channel. Side tone is on both channels regardless of split mode. This works well and is perfect for listening to recordings after the event.
The Flex DAX has other ideas. Each slice (VFO in common parlance) creates a separate mono audio channel. There is no way to merge two slice audio channels into a single stereo channel. I might be able to take two mono channels and merge them into stereo in StarLog but it's far from ideal because the simplex audio would only go to the left channel. Not a show stopper though.
Worse is that the DAX streams do not carry side tone. Indeed there is no DAX channel for side tone. As a 100% CW operator that is a show stopper - I would only be recording one side of the QSO. Come to that, the same applies on phone and probably on data modes. I can't find a solution to this problem, although I am making enquiries on the FlexRadio forum.
If, as seems highly likely, I am unable to use DAX for QSO recording I shall have to use one of the two analogue audio outputs. The Flex has separate headphone and low level speaker outputs, each with their own level controls. Both are more or less the same output level. I traditionally have headphones and speaker connected in parallel (donning the cans when the going gets tough, turning down the speakers if necessary). So I could use the loudspeaker output for that function and the headphones output, via the PC sound card, for recording.
That'll work but I had rather hoped to get away from wires given that the audio is already digitised and available in the PC to support SSDR.
At this rate it won't be too long before I can make the Flex 6500 my station radio. Just in time for the sunspots to disappear!
Subscribe to:
Posts (Atom)