The design decisions for the monitor were naive because the monitor was my first real C# project and I wasn't aware of the limitations of Windows Forms, the underlying .NET framework profile dependencies or the infamous serial port closure constraints. My goal for the monitor was to learn a lot about the 8410 amplifier and take a big leap into C# development. I accomplished both.
Now, it's time to reassess where this should go. I hesitated doing this before since it wasn't clear whether I was going to port the monitor for the 9500 amplifier as I've discussed that possibility a few times over the past year or so with RF Concepts.
My current thinking is that the monitor isn't structured for extensibility to another model even if that model is pretty close from a firmware behavior and telemetry perspective. I think it's best to develop a 2.0 version that starts from a clean slate and incorporates more professional coding standards and utilizes .NET development features which are current - such as Windows Presentation Foundation for the window and graphical layout. That means converting someone else's code as well since I utilized a library for the LED displays and it's currently anchored in Windows Forms technology just as the monitor is. And, I can incorporate the explicit multi-threading I used in the EEPROM utility to make the monitor handle serial port closures much more gracefully.
I've gotten requests for having the monitor work on Linux and the Mac. While redeveloping in C# won't address those desires, I think I'd be hard-pressed to port to C++ for those environments without first refactoring the existing monitor then attempting a C++ port. I avoided Java because I didn't think the performance would be satisfactory for timing-sensitive operations and interrupt handlers but that's just guessing. This fall I'll try to do performance testing of Java serial port interrupt handling and see if that looks like a viable path for supporting Linux and the Mac. I have very little C++ or Java experience so that will proceed slowly at first.
In the mean time, I have an outstanding request for a feature that I can add to the existing monitor - to split the tune/load table into two parts representing the low (CW) end of the band and an upper (phone) end of the band. This should accommodate the situation where you have to touch up between the lower and upper parts of the same band and the current tune/load table only allows one set of values.
The EEPROM utility currently only supports a configuration dump because that's all that the 2.03k firmware in the 8410 and 8406 support. Configuration restore (upload) and possibly table-style editing of parameters was the intended direction but that entails a fair amount of firmware coding on Gordon's part. Configuration uploads have to have lots of safeguards in place so the amp doesn't get "bricked" in the process should something interrupt or corrupt the upload. Gordon is currently 100% focused on the 4040 tuner project so the firmware work to support configuration uploads is currently on hold.
Development for me as a hobby has been difficult because time to devote to it has been sporadic and when I get an idea to try I'm not near the amplifier. Thus my Java performance testing may involve writing an amplifier emulator - code that responds to telemetry commands the same as the amplifier does. That would address the performance testing and, if successful, allow some freedom to re-develop the monitor without being tethered.
I'll add a forum section shortly to allow comments and ideas about where this project should go, what amplifiers should be supported, what operating systems should be included, etc.
Thanks for all your positive and constructive feedback on the monitor.
|Free forum by Nabble||Edit this page|