Topics

Some SW and doc issues

Marcus Gustafsson
 

Hi all,

last night I finished my PHSNA build based on a experimenters board with a AD9851 type II DDS.

So I started loading the Arduino SW and using the PHSNA program. As a SW guy I find the Arduino code a bit messy but it seems to work and I understand its legacy. I'm willing to help out so I wonder in what form I can do that? Patches? Complete files? Is there a code repository?
One question, why is 9600bps used as serial port speed instead of 115200 bps and will it improve sweep speed to change it?

As for the PHSNA.exe I had multiple issues with the parameters and memories files, crashes and settings not taking effect. Until I discovered that the file parsing depended on my computer locale, mainly that values should use , instead of . for decimals. After that it seemed ok, even it will probably take a while to get used to some of the UI quirks. Also here I'm offering my help even though I don't like doing UI code, so how can I help? Same questions as above.

User guide section about sending CW still says that the text should be last in the parameters file but now the field separator should be last.

Thats all, now I'm going to find why my PHSNA through sweep (1-60MHz) looks like a roller coaster with 10dBm difference in the output or power reading.

Best regards
Marcus


Steven Dick
 

Hi Marcus. Glad you are offering to help on the software side and the software developers in this group might want to take advantage of your expertise.  With regard to the 10 db difference, the following things can cause more than expected droop. In any case, using the polynomial correction should flatten the response nicely :
 
1. The inductors for the low pass filter tend to be on the high side if you use the recommended number of turns for the AD9851 version LPF.  I found that the inductors for the LPF required fewer turns than specified.  I ended up with 5 turns about 2/3 around the core instead of the specified 7 turns for L1 and L3 (.13uH) and 7 turns about 2/3 around the core instead of the specified 9 turns. If you have access to an LC meter, they can be checked.  Note:  an inexpensive LC meter called the LC-100A can be found on EBAY. Here’s one seller: http://www.ebay.com/itm/LC100-A-Digital-LCD-High-Precision-Inductance-Capacitance-L-C-Meter-Tester-/310633362131?hash=item485330f2d3:g:JKcAAMXQMmJRRrII
I have found it to be very stable even on small value inductors and capacitors and works well. Can be powered from USB cable or 12V with a selector switch.
2. The specified transformer at T1 can be improved by winding it as a bifilar (twisted pair) transformer rather than separate windings. See “Type II PHSNA transformer comparison.pdf” in the K1RF folder in files section.
3. At the higth end, you will get some droop due to the SINC (“sinX/X”) loss that occurs with a DAC or DDS output running at a particular clock sampling rate.  This loss is about 3dB at 80 MHz for a 180MHz clock which the AD9851 is running at. But this loss should be fairly small at 60 MHz so it gotta be T1 or large inductor values in the LPF or both.
 
REgards,
“Digital Steve”, K1RF
 

Sent: Friday, February 19, 2016 9:03 AM
Subject: [PHSNA] Some SW and doc issues
 
 

Hi all,

last night I finished my PHSNA build based on a experimenters board with a AD9851 type II DDS.

So I started loading the Arduino SW and using the PHSNA program. As a SW guy I find the Arduino code a bit messy but it seems to work and I understand its legacy. I'm willing to help out so I wonder in what form I can do that? Patches? Complete files? Is there a code repository?
One question, why is 9600bps used as serial port speed instead of 115200 bps and will it improve sweep speed to change it?

As for the PHSNA.exe I had multiple issues with the parameters and memories files, crashes and settings not taking effect. Until I discovered that the file parsing depended on my computer locale, mainly that values should use , instead of . for decimals. After that it seemed ok, even it will probably take a while to get used to some of the UI quirks. Also here I'm offering my help even though I don't like doing UI code, so how can I help? Same questions as above.

User guide section about sending CW still says that the text should be last in the parameters file but now the field separator should be last.

Thats all, now I'm going to find why my PHSNA through sweep (1-60MHz) looks like a roller coaster with 10dBm difference in the output or power reading.

Best regards
Marcus



This email has been sent from a virus-free computer protected by Avast.
www.avast.com

Marcus Gustafsson
 

Steve,

thanks for your prompt response. A few comments:
0. Unfortunately, since I have two distinct peaks in the curve the polynomial fitting won't be good. I'm currently collecting measurement data to see what's wrong. Right now it looks like both signal output and power detections has at least one fault each. I'll post my findings later.

Why bother with polynomial curve fitting when one could save all readings from one through sweep?

1. Filters, see my answer to you from one month ago in https://groups.yahoo.com/neo/groups/PHSNA/conversations/topics/2713 I ended up with similar results as you.
2. & 3 Good tips, I keep these in mind when debugging further.

Br
Marcus, SA5PMG

Nick Kennedy
 

Hello Marcus,


On Fri, Feb 19, 2016 at 8:03 AM, mankan@... [PHSNA] <PHSNA@...> wrote:
 

Hi all,

last night I finished my PHSNA build based on a experimenters board with a AD9851 type II DDS.

So I started loading the Arduino SW and using the PHSNA program. As a SW guy I find the Arduino code a bit messy but it seems to work and I understand its legacy. I'm willing to help out so I wonder in what form I can do that? Patches? Complete files? Is there a code repository?

​Well, there are two things that could or possibly should be done.  One would be to clean up the code - get rid of commented out sections and clean up the formatting. It's built on the original terminal mode code which had a lot of sections not needed by the Windows interface version. My hope was that the diners wouldn't have to see how the sausage was made. But anyone could clean it up and after we verify it still works the same, make it the official code and we'd all benefit.

The second thing would be to tweak functional aspects. Since the Arduino code basically responds to simple commands from the Windows program, any (or most) changes would have to be integrated with changes to the Windows program. But there's no reason not to do it. It's  just more complicated than revising only one program.

There's no repository other than what you see on the Yahoo site. The current Arduino code is there, but the Windows code is not. Over the history of the project, others have modified the Arduino code and written their own versions for their own use. Sometimes additions like the ability to use a widget that interfaces directly with Excel were interesting enough that I built them into the "official" code. (Thanks Jack G)

So I guess the answer is that anyone can tweak the Arduino code and test their results and if the improvements seem beneficial to the entire group, the changes could be incorporated into the official software. But even if they aren't incorporated, there's no reason "parallel" versions can't be added to the PHSNA files area. We may have some of that already. We just need to document what's what when things get complicated.​

Regarding the Windows C# code, I never attempted to publish or upload the code because of its complexity. But I don't mind collaborating. In fact, Ignacio Cembreros, EB4APL  got involved and made some changes that we see in the current revision. One thing he tried to tackle was the tricky problem of different decimal characters in various countries that you mention below. It's harder than it looks. He also cleaned up some formatting and UI issues similar to what you are interested in.

PHSNA was my first C# programming project and if I'd understood certain things about the language when I started as I do now, it would have been a lot easier! I'm not sure it would work much differently, although maybe it would open new frames for certain functions to reduce clutter.

 

One question, why is 9600bps used as serial port speed instead of 115200 bps and will it improve sweep speed to change it?

​That's a good question but it's been so long since the development phase that I'm not sure if much analysis went into the issue during development or not. I do know that the AD8307 has some response time and there is a bit of intentional delay in the program to accommodate this. So whether reducing the delay caused by serial transmissions would appreciably improve speed - I don't know. I probably stuck with a speed that was in a basic kernel of the code when I picked it up. Historically, I've been a bit wary of the highest speeds in serial I/O for fear of transmission errors. Whether that's a concern with modern hardware, I don't know. ​

 


As for the PHSNA.exe I had multiple issues with the parameters and memories files, crashes and settings not taking effect. Until I discovered that the file parsing depended on my computer locale, mainly that values should use , instead of . for decimals. After that it seemed ok, even it will probably take a while to get used to some of the UI quirks. Also here I'm offering my help even though I don't like doing UI code, so how can I help? Same questions as above.

User guide section about sending CW still says that the text should be last in the parameters file but now the field separator should be last.

​Thanks. I try to keep the user's guide current and will look at that.​

 


Thats all, now I'm going to find why my PHSNA through sweep (1-60MHz) looks like a roller coaster with 10dBm difference in the output or power reading.


​I was also going to suggest the polynomial coefficients, but if you're looking at raw data, it must be a hardware issue.

Coincidentally, I just did a minor edit to the Windows code last night, for the first time since May, eight months ago. It took me 30 minutes to find the latest revision of the code and remember how to fire up the IDE.

​I'll be happy to fix nagging UI issues myself, if the fix isn't too difficult. For instance, someone recently encountered the ambiguous "RF On" and "RF Off" button problem. If it says "RF On" does that mean that clicking it will turn the RF output on, or does it mean it's on now?  In fact, I've been using my PHSNA to generate signals for my own receiver design project recently, and that one's been bugging me. So I mean to fix that. Also, that button doesn't integrate well with the "Send CW" button. I need to fix that too.​


I'll be out of town over the weekend but can participate in further discussions as of Monday.

73-

Nick, WA5BDU​
 


Best regards
Marcus



Marcus Gustafsson
 

Nick,

ok I'll give it a try to cleanup the Arduino code and upload it here for people to test.

As for the Windows program I can start with reporting UI annoyances, like if you showing a graph and press another button on the right side the UI is not updated (or maybe it is behind the graph). Maybe later I also could helping out improving the parameter file parsing and error reporting. I know, locale handling and testing is painful, so first order of business would be to put that code into a unit test framework.

Serial port speed: Maybe my question is a case of premature optimization but time gained could perhaps be used to do multiple ADC reads and averaging the value.

But first I need to get my PHSNA HW working properly.

Best regards
Marcus, SA5PMG

N5IB
 

Thanks, Marcus, for jumping into the software pool. Had it not been for Nick taking the plunge a couple of years ago, the PHSNA would never have gotten this far.

May I suggest that you create a folder in the files area to hold your software postings - call it "SA5PMG Software" or something like that. Then create two subfolders within it - one for the Windows PHSNA stuff, both the .ino code. the .exe, and related data and user information - and the second for the terminal version .ino code and associated documents.

That'll make easy for folks who want to try it out to find all the relevant software pieces in one place.

Thanks again,
Jim, N5IB



Marcus Gustafsson
 

Hi all,

I've uploaded a cleaned up version of the Arduino code into the SA5PMG_software folder.
I have mainly tested it by doing response sweeps and some manual control. CW sending seems to work as well. Feel free to try it out and let me know if anything looks weird.

I have also analyzed the effects of serial port speed being 9600 bps. One round trip of frequency setting and read ADC commands takes 19.8ms. This is measured by toggling a free IO pin and using a oscilloscope.

One round trip transfers 9 bytes of data which takes 9.4ms so that is half of the round trip time. So there are performance to be gained here.

Increase to 152000 bps instead would give a theoretical round trip time of 10.2ms. So I've added a new serial command to the Arduino code to switch up the serial speed as well as increased the version to 1.7. This is completely untested but if I get access to the Windows code I could give it a try to utilize it. Some of gained performance could perhaps be used to do multiple ADC conversions and take the average before reporting the value back to the host computer in order to get more stable readings.

Other highly desirable features are remembering the sweep settings between restarts, at least step and stop frequency.

A more advanced feature I would like to see is to be able to do a through calibration sweep and use those values instead of the polynomial curve fitting. Would that be useful?

Best regards
Marcus, SA5PMG

Nick Kennedy
 

Sounds interesting, Marcus.

Almost cutting the sweep time in half would be worthwhile, I'd imagine. Assuming that a 115 kB/s rate would be reliable.  I can zip up the whole C# project folder and send it to you, but take a deep breath before you have a look. But just hunting down the statements that set the baud rate shouldn't be too difficult.

Remembering sweep settings shouldn't be too difficult (famous last words). Just create another data file to be read at startup and written as part of the shut down process.

"A more advanced feature I would like to see is to be able to do a through calibration sweep and use those values instead of the polynomial curve fitting. Would that be useful?"

I'm not sure.  What do you have in mind?  Save a large number of points (thousands?) and interpolate between them for the correction value rather than use the polynomials? Do you think that would add a worthwhile increase in accuracy?  I suppose if there is a problem there, we could increase the order of the polynomial expression too.

73-

Nick, WA5BDU

--BTW, I found a bug a while back. I used my measurement receiver for the first time in a long time and clicking on the function caused an error. I completed my task by using sweeps and manually calculating results, but I do need to fix that bug sometime.


On Sun, Mar 13, 2016 at 12:02 PM, mankan@... [PHSNA] <PHSNA@...> wrote:
 

Hi all,

I've uploaded a cleaned up version of the Arduino code into the SA5PMG_software folder.
I have mainly tested it by doing response sweeps and some manual control. CW sending seems to work as well. Feel free to try it out and let me know if anything looks weird.

I have also analyzed the effects of serial port speed being 9600 bps. One round trip of frequency setting and read ADC commands takes 19.8ms. This is measured by toggling a free IO pin and using a oscilloscope.

One round trip transfers 9 bytes of data which takes 9.4ms so that is half of the round trip time. So there are performance to be gained here.

Increase to 152000 bps instead would give a theoretical round trip time of 10.2ms. So I've added a new serial command to the Arduino code to switch up the serial speed as well as increased the version to 1.7. This is completely untested but if I get access to the Windows code I could give it a try to utilize it. Some of gained performance could perhaps be used to do multiple ADC conversions and take the average before reporting the value back to the host computer in order to get more stable readings.

Other highly desirable features are remembering the sweep settings between restarts, at least step and stop frequency.

A more advanced feature I would like to see is to be able to do a through calibration sweep and use those values instead of the polynomial curve fitting. Would that be useful?

Best regards
Marcus, SA5PMG


Marcus Gustafsson
 

Hi Nick,

looking forward to the zip file.

Yes, the increased serial speed has to be reliable. A more elaborate way would be to allow the user to select the speed used.

Sweep settings: If the parameters file parsing is improved it could be added there and still be backwards compatible but the easiest way is probably another file just as you say, or maybe use the registry.

Calibration sweep: Yes, exactly store values and interpolate. Thousands of values is no issue for the PC but the Arduino EEPROM if stored there would just able to store a couple of hundred values.

Increased accuracy? No idea, but my PHSNA build does not have the normal rolloff in its output and the polynomial has some trouble handling some dips and spikes in the curve. This might be related to the problems I been having (see the Sweep output debugging thread) and I have not yet received any ERA-3SM+ to swap out the other MMIC to see if that helps. Or maybe build an AGC or go to the bottom of the spikes and dips or bury the problem with software :-).

This is also why I've been looking into doing multiple ADC operations per frequency step.

Br
Marcus, SA5PMG


On Sun, Mar 13, 2016 at 8:09 PM, Nick Kennedy kennnick@... [PHSNA] <PHSNA@...> wrote:
 

Sounds interesting, Marcus.

Almost cutting the sweep time in half would be worthwhile, I'd imagine. Assuming that a 115 kB/s rate would be reliable.  I can zip up the whole C# project folder and send it to you, but take a deep breath before you have a look. But just hunting down the statements that set the baud rate shouldn't be too difficult.

Remembering sweep settings shouldn't be too difficult (famous last words). Just create another data file to be read at startup and written as part of the shut down process.

"A more advanced feature I would like to see is to be able to do a through calibration sweep and use those values instead of the polynomial curve fitting. Would that be useful?"

I'm not sure.  What do you have in mind?  Save a large number of points (thousands?) and interpolate between them for the correction value rather than use the polynomials? Do you think that would add a worthwhile increase in accuracy?  I suppose if there is a problem there, we could increase the order of the polynomial expression too.

73-

Nick, WA5BDU

--BTW, I found a bug a while back. I used my measurement receiver for the first time in a long time and clicking on the function caused an error. I completed my task by using sweeps and manually calculating results, but I do need to fix that bug sometime.


On Sun, Mar 13, 2016 at 12:02 PM, mankan@... [PHSNA] <PHSNA@...> wrote:
 

Hi all,

I've uploaded a cleaned up version of the Arduino code into the SA5PMG_software folder.
I have mainly tested it by doing response sweeps and some manual control. CW sending seems to work as well. Feel free to try it out and let me know if anything looks weird.

I have also analyzed the effects of serial port speed being 9600 bps. One round trip of frequency setting and read ADC commands takes 19.8ms. This is measured by toggling a free IO pin and using a oscilloscope.

One round trip transfers 9 bytes of data which takes 9.4ms so that is half of the round trip time. So there are performance to be gained here.

Increase to 152000 bps instead would give a theoretical round trip time of 10.2ms. So I've added a new serial command to the Arduino code to switch up the serial speed as well as increased the version to 1.7. This is completely untested but if I get access to the Windows code I could give it a try to utilize it. Some of gained performance could perhaps be used to do multiple ADC conversions and take the average before reporting the value back to the host computer in order to get more stable readings.

Other highly desirable features are remembering the sweep settings between restarts, at least step and stop frequency.

A more advanced feature I would like to see is to be able to do a through calibration sweep and use those values instead of the polynomial curve fitting. Would that be useful?

Best regards
Marcus, SA5PMG



David Collins
 

HI Marcus,

The MSNA does that sort of calibration.  The user does a scan over a wide frequency range (e.g., 1 to 61 MHz) and pressing a hot key transfers the data to the calibration buffer.  Future scans are then calibrated by subtracting a value from the calibration buffer from the ADC reading.  Since the change is gradual and smooth, we just pick the calibration data for the frequency closest to the current frequency.  Typically a scan like this will show 4 to 6 dB drop across the 60 MHz frequency range.  (We recommend setting the DDS output to 0.0 dBm at 1 MHz and using the calibration data to adjust for higher frequencies.)

 If you want to do this type of calibration in the Arduino code you will find that the UNO and NANO do not have enough RAM.  Currently I am working with the Measurement Receiver and have expanded the MSNA's data buffer to 4,000 points.  This is enough to hold one MHz of data with a frequency step of 250 Hz.  To make the additional RAM available, I reduced the calibration buffer size to 200 points and save 200,evenly spaced, data points in the calibration buffer.  Since you know the extent of the frequency scan, you could compute "N" in advance and and just pick off and save every Nth data point as it passes by.


73,
Dave Collins - AD7JT