Posts Tagged ‘Programming’
In today’s episode, we have our final listener interview from the Hamvention 2014 Indiegogo campaign that actually ended back in February. Mike Maydaniuk, VA7XXM, was kind enough to donate to our Hamvention ambitions, and now comes on the show to share with us his thoughts on Linux, amateur radio, life, and some random silliness. Hope you enjoy, and please make sure to send us feedback, either via e-mail, social media or voice mail.
73 de The LHS Guys
|My first Android app|
I thought that some of you might be interested to look at the first app I have completed using Basic4Android (B4A) called WhereAmI. It’s no great shakes as an app, and I think there is at least one other in the Android Market that does a similar job. My app’s unique feature is that besides the locator it shows the national grid reference (NGR) as well as the Worked All Britain (WAB) square. WAB is a popular activity on the low HF bands over here.
Because NGR and WAB only cover the UK, my app will not be very useful if you are outside of Great Britain. Indeed the app will probably blow up if you try it outside the UK as I haven’t included any test that the user is within these sceptred isles.
I’d rather not say how long the app took me to complete, but it was far longer than expected given that I had already written code to convert from lat/long to grid locator in VOAProp. That code was in Pascal, and the trouble was caused by the fact that Basic4Android does not have equivalent functions to those in Pascal, or even Visual Basic, so I could not just do a copy and paste. In the end I found a conversion routine written in C++ and converted that to B4A’s dialect of Basic. From there on it was easy, as there is a user-written library in B4A to handle conversions to/from National Grid references, upon which the WAB programme is based.
If I don’t try something else I might have a go at displaying a Google Map centred on my location, as one of the examples that come with B4A does just that.
I don’t plan on publishing any of the apps I create in Google Market (or Google Play as I think they now call it). I am doing this just for fun. Think of this as the programming equivalent of those radio projects knocked together on a breadboard or built Manhattan style, with no expectation that they will get put into a nice box.
If there is any interest I will make available the B4A project files as a zip file so that folks can play with them, hack them about or use them as a starting point for something better.
The runaway success of the Elecraft KX3 has resulted in a sharp increase in the number of users of KComm. Even those who use a full-featured logging program in the shack find the simplicity of KComm and the compactness of its user interface (which was designed to fit a netbook) better suited to portable operating.
I received an email from a KComm user in Vienna, Wolfgang OE1MWW who wrote that he found the option to “Use PSK modem” (which uses AE4JY’s PSK Core DLL to operate PSK31 using the sound card) was disabled on his laptop running Windows XP SP3 though it was enabled on his desktop running Windows 7 64-bit. Wolfgang eventually found that replacing the file PSKCore.dll that was installed by KComm with one dowloaded from AE4JY’s website cured the problem.
I am surprised and a bit mystified as to why this occurred. My shack PC also runs Windows XP SP3 (I prefer to stay as far from the bleeding edge as possible) and it uses the same version of PSKCore.dll as is installed with KComm.
KComm’s version is much smaller so I’m hazarding a guess (since I can no longer remember) that it may have been compressed using UPX, an executable file compressor. I used to have a bit of a mania for compressing executable files so I could claim how small they were compared to certain other ham radio bloatware, but in these days of 100GB hard drives it’s probably rather fatuous. Possibly the compression caused an issue with some security software?
Whatever the reason, I’m grateful to Wolfgang for discovering a solution. I have added a note to KComm’s Troubleshooting page and updated the installer package to include AE4JY’s copy of the PSKCore.dll so hopefully new users will not encounter this problem.
Up until I got an Android smartphone, there has not been a single programmable device that I’ve owned and not tried to write my own programs for it. However, programming for Android devices seemed to be fiendishly difficult, requiring a good knowledge of Java (which I haven’t got) so I didn’t attempt it. The other week I saw an article in a computer magazine that went through describing how to create programs using a tool called Basic4Android. It seemed similar enough to other development tools I have used such as Visual Basic, Delphi and Lazarus. So I thought I would download the trial version and have a play.
|The Basic4Android development environment,|
I soon discovered that the trial version is pretty limiting. It’s enough to get a feel for the environment and the development process by creating “hello world” apps and suchlike, but in order to do anything interesting you need to use libraries and these are only accessible using the full paid-for version.
There are two full versions of Basic4Android you can buy: the Standard version which costs $49 and includes support and free upgrades for two months, and the Enterprise version which costs $99 and includes support and free upgrades for two years. As I’m not an Enterprise, only a dabbler (and a cheapskate one at that) I bought the Standard version. With hindsight that was not such a good idea, as I discovered after purchasing that only current paid-up users get access to the download links for additional libraries, even user-written ones, and access to the support forum. So after two months I’m on my own. A false economy, I think.
|Sophisticated GPS apps can be developed|
Basic4Android is a very powerful development tool and I don’t think there is much you couldn’t do with it if you’re clever enough. The language is object oriented like any modern Basic, and objects exist to let you access the internet, draw charts, access SQL databases and much more. You can access the Android device’s GPS via a fully featured GPS library. There is even code to work with Google Maps. I have no intention of developing an Android version of APRSISCE (as if I could!) but Basic4Android looks powerful enough to make that possible.
So far I haven’t learned much about Basic4Android programming that’s worth sharing with people, but here are a few things I wish I had known prior to buying.
There is no need to pay the full prices I mentioned earlier. Once Google finds out you are interested in Basic4Android, ads to buy Basic4Android with 30% off will follow you around the web. To get the deal, click on one of them.
There are two options you can use to pay for Basic4Android, PayPal and Plimus. If you are in Europe then be sure to use the PayPal purchase buttons. If you use Plimus then you’ll get stung for VAT which will bump up the price 20%.
Better still you can get Basic4Android Enterprise version with two years’ updates and support at half price by using the coupon code dnxyif. Unfortunately this is only valid if you use the Plimus payment option so there is no avoiding VAT if you are in Europe. But even with VAT it’s still the best deal I think. I hope that helps someone.
I have found the solution to a problem that had been bugging me for ages: Omni-Rig did not work with JT65-HF. It was not a major bother for me as it could be worked around by the simple expedient of setting the frequency manually. But after an episode yesterday when I thought I was on 15m and was actually on 20m I decided to look at the issue again.
The solution turned out to be very simple and I stumbled across it by accident. You must start OmniRig before you start JT65-HF! That may seem obvious, but in fact other programs that use Omni-Rig manage to do so without it being run first. Which is why it never occurred to me to try that before. Doh!
Unfortunately the communication between the programs only works one way. JT65-HF can read the frequency from the rig using Omni-Rig but it can’t set it. As I have the JT65-HF source I took a quick look to see if I could fix the problem, but it would not be easy. A major discouragement to tinker with the source code is the fact that the newly-compiled program breaks the link between HT65-HF and JT-Alert. So I am not going to venture down that road. When it comes down to it I’d rather have my alerts than have rig control.
I had an email from a KComm user from Russia today. He reported that when he clicks on a spot in the DX Cluster window the message “Invalid floating point operation” appears.
I guessed immediately what the cause of this was. It’s a problem that has been the bane of my life ever since I started programming as a hobby. In most of Europe the character used for the decimal point is a comma, not a dot (or period as our American friends say.) If your program is being used in a European country, adopts the correct regional settings and then reads some data expressed in the US or British way (such as the frequency in a DX Cluster spot) when it tries converting data to a binary floating point value it will come up with an error. If the European Union was actually any use you might think they would have standardized the representation of numbers by now, but hey…
If you are affected by this issue then a workaround is to use the Regional Settings in Control Panel to change the decimal separator to a dot instead of a comma. I’ve looked at the KComm source code and fixing the problem doesn’t look as if it is going to be easy so a solution may be a little while in coming.
Today started off with me continuing to compare the two morse decoders MRP40 and CW Skimmer in view of PC4T Paul’s insistence that the latter was the better morse decoder. When I heard someone calling CQ with no takers I took pity on them and returned their call. JY4NE and C6AKQ went into the log very quickly, in fact so quickly I was left wondering if I had actually worked them. Some people moan that all digital mode operators do is exchange macro files, but in a lot of CW QSOs you barely exchange anything!
Next I replied to a Russian station who was a bit more chatty. Unfortunately my logging program KComm locked up in mid-QSO. It was embarrassing because I was sending from the keyboard and didn’t even have a key plugged into the transceiver so I couldn’t continue. I’m sure there will be people who would add me to a blacklist for this, but these days I tend to treat CW as just another digital mode. Hence my interest in good decoder programs. 🙂
KComm has a feature where you can insert the answer to a multiple choice question into the outgoing text. It is expressed like this: %?question|answer 1|answer 2|answer3? which would cause a box to pop up saying “Question” and you click on the answer you want inserted. It was this feature that was causing the program to lock up.
After a couple of hours tracing code in the debugger I could not see what the error was, unless it was a bug in the Lazarus library software. The feature had been in KComm since many versions ago, but this current version was compiled with a new version of Lazarus, so that was a possible explanation. Eventually I managed to modify my program code to avoid the error, with the result that this afternoon there is now a version 2.02 of KComm.
I tested the update by having a QSO with Mik EW8O in Belarus. Then I decided it was time for a rest – I find debugging code these days is mentally exhausting!