As you probably know, using an LD-1TR with HDSDR v2.12 or later requires that ExtIO_Si570.dll, which is part of the CFGSR installation, be copied to the HDSDR installation directory. On a 64-bit computer, the HDSDR installation directory is normally C:\Program Files (x86)\HDSDR.

On a 32-bit computer, that’s all it takes. ExtIO_LD1.dll loads ExtIO_Si570.dll, and uses a couple of its functions. As it has turned out, a 64-bit installation also requires installation of libusb drivers, and the files libusb0.dll and libusb0.sys have to be copied to the HDSDR installation directory. Fortunately, that isn’t as bad as it sounds. Read the rest of this entry »

Now that the LD-1TR plays nicely with HDSDR, operating PSK-31 is a LOT more convenient.

Read the rest of this entry »

The recent software update, V1.5, included several new features. One of them gives the operator the ability to save the current LO frequency to the LD-1(B, B2, C, or TR)’s internal flash memory. Read the rest of this entry »

As far as I know, there is absolutely no problem with the new update (V1.5) of Lazy Dog software when installed on a 32-bit computer. It seems there is a solveable problem when it is installed on a 64-bit computer running Vista or Windows 7. The problem only affects transmitter operation with HDSDR. Here’s what I know so far: Read the rest of this entry »

…as promised. Sorry about not posting it on Monday, but thanks to Patricia for reminding me. This mod will prevent the transmitter bias from being turned on while the firmware is updated. The red LED will still come on, but that isn’t a problem. Also, there’s no reason to do this if your radio is a receiver only.
Read the rest of this entry »

It took a couple of days longer than I had hoped, but it’s available to download at lazydogengineering.com/Downloads.html. Here is a summary of the improvements and new features:

• Now compatible with the latest version of HDSDR, for full and reliable control of transmitter functions
• External PTT switch wired to the accessory jack will control HDSDR T/R switching
• LO frequency can be saved to the LD-1B/B2/C/TR’s internal flash memory
• LO frequency saved in flash memory is automatically resored on startup
• LO frequency saved to flash memory may be restored by the operator at any time
• Restoring the LO frequency updates HDSDR, SDR# or Winrad.
• Running the installer puts dlls in existing installation folders for HDSDR, Winrad and SDR# (SDR# installed at C:\Program Files\SDRSharp)
• Firmware now includes a watchdog timer to reset the microcontroller if it “freezes up”
• New and Improved User’s Guide (also available at the documents page)

Download, install (don’t forget to install the firmware update) and enjoy!

73 de NI9N

I had everything done this morning, all working and built, documents updated. Then I decided I’d better test the new dll with Winrad and SDRSharp, not just HDSDR. It doesn’t work with them, apparently because of the code that was added to activate transmitter support. That means building a different version of the dll for Winrad and SDRSharp, which won’t be difficult. Unfortunately, I won’t be able to get on it until late this afternoon, so it’ll be another day before it’s released. Sorry, but it won’t be much longer.

I should point out that this doesn’t mean separate releases for HDSDR and Winrad/SDR#. There will be one release, one installer. The installer will automatically put the correct dll in the install folders for HDSDR, Winrad and SDR#.

It has turned out that the bootloader firmware can’t overwrite itself, so there’s no way to create a new version which will start up with P2.0, the signal that turns on the transmitter bias, pulled low (transmitter bias off). That’s the bad news, but the good news is that there’s an easy hardware mod that will keep the transmitter bias turned off during the firmware update process. It involves nothing more that installing a 1/8 W, 10K resistor between two of the pins of the 8-pin header. I’ll post detailed, illustrated instructions today or tomorrow. More details later in this post.

I intend to make the software/firmware update available by the end of the day today.

More good news: everything else works. The LO is saved to flash memory when the user requests it, and when it’s restored the display in HDSDR is updated (I still have to test it with SDR# and Winrad). The watchdog timer works. The external PTT button works as it should, and HDSDR controls the transmitter hardware. However, some testing is still needed. Software testing is almost always problematic, especially when there are possible timing issues. It’s never enough to try the new features once or twice, you have to hammer on them to see if they’ll break. I intend to finish the testing by the end of the day, but that doesn’t necessarily mean I’ll have an update posted for downloading before tomorrow.

After the software development and testing are all done, there’s the final build process. Here’s how it works: The LD-1 software comprises one Visual Studio “solution” and one Silicon Labs IDE “project”. The Visual Studio solution, in turn, comprises three projects: one project is the LD-1 standalone control app, the second project is the ExtIO dll (which is required by the LD-1 Control app), and the third VS project is the “setup” project. Building the ExtIO project results in a new ExtIO dll file, and building the LD-1 control app produces a new executable, LD1Control.exe. I’ll come back to the “setup” project in a moment.

Building the Silicon Labs IDE project produces in a new LD-1TR.hex file. That’s the firmware upate which you will install with the bootloader, and it’s built in the Silicon Labs IDE project using the Keil C compiler, C51 assembler and linker.

Back to Visual Studio: Building the “setup” project creates a new MSI installer. That’s the file you download from lazydogengineering.com and run on your PC. It creates several folders and puts files in them. It also looks for the folders where HDSDR, Winrad and SDR# are normally installed and (if any of them exist) it puts copies of ExtIO_LD1.dll and SiUSBXp.dll in them. I create an installer this way to try to make the installation process as foolproof as possible. I still get the occasional call or email from a customer who has installation problems, but there are probably fewer of them this way.

Creating an MSI installer is intended to make the customer’s life easier, and mine, too, in the long run. It means fewer calls from help from frustrated customers, but it means more testing. After I’ve tested the ExtIO dll and the LD-1 control app to make sure they work correctly, and then build the new installer to deploy them, I need to test the installer to make sure it pulls in the correct version of everything (dlls, hex file, executable, and documentation) and puts them in the right place. I don’t remember ever getting that 100% right on the first try, but it has to be right before I post it for you to download.

Now, a little more about that hardware mod: when the microcontroller is powered up or otherwise is reset, the IO ports are in their default condition. That means each IO pin is configured as digital (not analog) IO, open-drain (not push-pull).

Push-pull means there’s a p-channel MOSFET between VDD (the power supply) and the output pin, and an n-channel MOSFET between the pin and ground. Turning the p-channel MOSFET on shorts the pin to VDD, resulting in an output of “1″; turning the n-channel MOSFET on shorts the pin to ground, for a logic “0″. Turning both MOSFETs on at the same time results in smoke, so it’s never done (intentionally).

Open-drain means there’s no p-channel device. An open-drain output is normally used with an external (or internal) “pull-up” resistor. When the n-channel MOSFET is on, it “pulls down” the pin hard enough to overcome the pull-up resistor, but when it’s off the resistor “pulls up” the pin hard enough to overcome the very high “off resistance” of the MOSFET.

If there’s no pull-up resistor and an open-drain output is supposed to be at logic “1″, it’s essentially unconnected or “floating”. That means its voltage could be anything between 0 and VDD. In the case of the LD-1TR, it “floats” to a high enough voltage to turn on the transmitter bias, but ONLY while updating the firmware. Once the new firmware is loaded and started (by resetting the microcontroller, by cycling the power or by clicking “reset” on the bootloader screen) the pin that controls transmitter bias is reconfigured as push-pull and set to “0″, making sure transmitter bias is turned off until the firmware turns it on.

Installing a 10K pull-down resistor between the transmitter bias control pin and ground pulls the pin down hard enough to keep it at ground as long as the pin is configured as open-drain. Even though it comes up as a logic “1″, the resistor keeps it from floating up and turning the transmitter on. When the pin is reconfigured as push-pull, the internal MOSFET can pull up hard enough to overcome the external pull-down resistor, thus turning the transmitter on when it is supposed to be turned on.

The new watchdog timer resets the microcontroller if the firmware ever freezes up. Resetting the microcontroller ensures that the transmitter is turned off, until the firmware turns it on under your control.

I’ve been hard at work on the software update I promised in my last post, and it’s going well. As you may recall, I promised that an external PTT button wired to the LD-1TR’s accessory jack (that’s the 3.5 mm stereo jack right next to the USB connector) would control the hardware AND HDSDR, and that is now working. The PTT button should be wired to short the ring of the accessory plug (that’s “ring” as in “tip, ring, shield”) to the shield. When that happens, the microcontroller debounces it and then signals the ExtIO DLL via the USB connection. The DLL sets a callback status code which indicates to HDSDR that transmit has been requested, and HDSDR calls the DLL function that switched from receive to transmit. When the PTT button is released, the microcontroller signals the DLL again, which, well, you get the idea. So far it works with 100% reliability, so I’m pretty happy with that feature.

The second feature is one I’ve wanted to implement for a while. I’d like the operator to be able to save the current LO frequency to the LD-1TR’s flash memory, and have that be the frequency it comes up on when it’s powered up. That already happens when using HDSDR or Winrad, because they both remember the LO and Tune frequencies from the last session. I want it to work with other software like SDR Sharp (or CW Skimmer, Tim!) as well. I’ve had software working for a while that restores the LO from flash on power up, but it doesn’t communicate the LO frequency to the SDR software. As I said, that doesn’t really affect users of HDSDR and Winrad. I’ve wanted the DLL to send the LO frequency to the SDR software on startup, and hadn’t got that to work until now. I also want the operator to click a menu or button on the LD control panel to restore the frequency saved in flash at any time, and send it to the software. I’ve got that working now. It isn’t 100% reliable yet. Sometimes I have to click “Restore LO” two or three times before HDSDR gets the restored frequency, but I think I know how to fix that.

The (almost) bottom line is that I should have both the PTT and the Save LO / Restore LO features working by the end of the day. It’s almost the bottom line, because there are a couple of other little improvements I’d like to make to the firmware. After I’ve got everything working, I’ll test it thoroughly to make sure I haven’t broken anything. I hope to have that done and release the update by the end of tomorrow.

If you’ve been reading this blog for a while, you know that I’ve wanted to support the transmit capability of the newer versions of HDSDR. If you have an LD-1TR, you’ve been stuck with HDSDR v2.11 which leaves a lot to be desired. Well, the wait is almost over. I am testing software that will fully support the current version of HDSDR, v2.15! Read the rest of this entry »