The 6M-160M HPSDR Transceiver Project Begins

[W1AEX]

Have you run the little "DPC Latency Checker" utility to measure your system's ability to handle real-time SDR streaming and processing? It's a tiny executable that needs no install, you just run it. It evaluates how your system responds to delayed procedure calls as services and hardware make demands on the OS. Run if for a minute or two while you have PSDR doing its thing and it will tell you if your system is up to the task.

http://www.thesycon.de/dpclat/dpclat.exe

[WA1GFZ]

I sent Tom the link to run it from HPSDR Yesterday. I should run it also just to know where I stand. I think changing priority may have been my problem with mouse and keyboard locking up.

[WA1GFZ]

Tom,
I run hot and cold with HPSDR. I agree a very good test tool. Sometimes I don't feel like running the computer. I find most of the time I have the Mercury receiver running in parallel with the Racal. The KAZ system is usually on the HPSDR. Interesting that I have good front to back between the two antennas when I monitor myself with a scope. Maybe 10 dB with the dipole 100 feet away.

[K1JJ]

Thanks for the test link Rob. Yes, I'll run it today and see what it sez.  BTW, that was a cool recording you did yesterday of the 11mW PW signal here. Gawd it was PW!  It's funny to think that if I went from 11mW to only 110 mW it wud come up 10db. And from 110mW to about a watt it wud increase another 10db... :-)


Frank - I still have some energy left in me today to try a few more things with the rig. I will add in the twisted power supply leads for the 12V and 5V that goes to the Atlas backplane.  However, I think I may have damaged Penny with of the relay it keyed. I wish there were warnings on the website about that. It said "60V, 100ma" capability, but nothing about inductive loads. It was a small 12v RS relay I used with a diode across it. The problem now seems that Penny is very noisy on unkey causing that spike and also will very occassionally lock into a freq sweeping mode when unkeyed, requiring me to shut off the power and reboot. 

I hear this spike even when all the connectors are off and I MOX key it with the mouse. I didn't remember this spike before I hooked up that little 12V relay... sigh.  Now I have no relay keyed by Penny and it works most of the time except for the spike on unkey. 

T

[WA1GFZ]

put your scope on 13 and 12 volt supplies. Switch to ac coupling on scope vertical input. Look for a transient on each voltage when you unkey. AC coupling allows you to set the scope at 1 volt and still have the trace on the screen. This sounds like a power supply issue. You might reload firmware as a last resort.
make sure you have a 50 ohm load on the output.
I have never seen this sweeping mode you talk about.

BTW those little driver chips are pretty tuff. We have been using them for almost 30 years. I notice you don't have a ground return between LPU and Atlas so current must be going through the chassis. That is NG.

[K1JJ]

Yes, I have a PS gnd wire between the LHU and Atlas. Unless you are thinking of something else.  Are you talking about an additional gnd strap? There's three leads connected - one for 12V, one for 5V and one for gnd return.  I'll replace that with twited pairs today anyway.

I'll check the PS with the scope on AC and magnified up. Yes, maybe firmware too.  I sent a msg to both Phil and Joe about it to see what they think too.  Gads, a bad Penny wud be a deal breaker for me. I need another Merc anyway and this wud push the cost up, esp if I had to get a new computer. Flex 5K-price city.

I was really impressed by the opposite sideband suppression. I had the lows going down to 0hz and the opp was quiet. Mormally an FT-1oooD type filter rig wud make S9 rumbles.  The TX skirts are unreal. Yes, the SDR had its advantages.

Just dug of the generator. That snow was 4' in places like an iceberg. Never seen it so deep. Just imagine another 10" with ice.

BTW, when keying the pin 1 of Penny with contacts, they say to use "ground".  Then they list a pin for digital ground and audio ground. Which ground do I use with pin1?  I ended up using chassis ground cuz it didn't work with digital gnd at all.  Hope that didn't hurt something when I tried it.

T

[WA1GFZ]

You should have 4 leads. 5, +12, -12 and ground. Ozy needs -12.
PTT referenced to D ground
I think you should have mounted LPU the way it was designed to interface.
The computer power plug is fine. I never had any problems when I used it.

My showblower shoot is all the way up so I'm hoping for rain

[K1JJ]

Yes, just checked and I have four leads there. I forgot about the -12V.

Later I will erase and load the firmware again.    If I can't find the problem I'll stop by and we can plug these boards into your Atlas and maybe screw yours up too...

T

[WA1GFZ]

The only common thing between Penny and Mercury is the power supply and Atlas data bus. Try plugging penny into a different slot.

[WA1GFZ]

Tom go into set up and change your clock source and see what happens. If you are using
Ppenny change to Mercury

[W1AEX]

When you think about everything that's going on as SDR rigs are keyed and un-keyed it's not surprising that issues like this come up. There are complaints from some Flex users about this as well with certain versions of PowerSDR. Issues with leading edge spikes while driving solid-state power amplifiers have been mentioned, along with complaints of loud noise bursts appearing when transitioning from transmit to receive. My current version of PSDR is not exhibiting either of those behaviors, but the un-keying issue was a problem for me with an early beta version. I wonder if what you are seeing is related to the version of PSDR the HPSDR guys used?

Here is another short audio sample showing the pileup you created yesterday when you asked if anyone was copying your little 10mw signal. Think how much stronger you would have been if you had used your modified Radio Shack "ARCHER Space Patrol" walkie talkie that ran 10 times the power!

[WA1GFZ]

You know Tom you are using a different power sdr program from Joe. Maybe Rob hit on something. Maybe you should ask him. I looked at penny schematic and can't find anything common to both boards.

[K1JJ]

Frank,

I tried swapping the boards around yesterday - no change. I was trying to eliminate the Atlas board.  I also tried the different clocks and no change either. Still have that unkey spike.

Rob, that's a cool recording. You can certainly hear the difference between 10mW and the guys coming back who were QRO at 1-5 watts..  

I'm glad you mentioned others were having PTT spikes too. Maybe it's the new diversity PSDR version. I will reload an older version if these newest fixes don't help.  I just added twisted power supply pairs, though that will probably not solve it. But also reloading the Penny firmware now. Then will look at the PS for spikes on the scope.

BTW, I was running some tests last night looking at cleanliness. I found it real easy to overdrive the audio and produce peak crud. Listen on a RX to the opposite sideband on ssb and when the crud starts, the opp will show it first.  There needs to be some kind of limiting there, though maybe the line input will help tame it down. So far the line .bat files did NOT work to change it from mic in to line in. I mentioned this to Phil and we'll see if he gives it another go.


Thanks for the additional info.

T

[W1AEX]

BTW, I was running some tests last night looking at cleanliness. I found it real easy to overdrive the audio and produce peak crud. Listen on a RX to the opposite sideband on ssb and when the crud starts, the opp will show it first.

Your observations are right on the mark. Opposite sideband suppression with SDR platforms can be outstanding, but there is enough latitude in the user settings that it can also be horrendous. If gain distribution throughout the software audio chain is set correctly (never crossing the 0 dB point in PSDR) it should run very cleanly. Unfortunately, in an attempt to sound loud, you will hear stations pounding the audio and generating tons of artifacts.  Another setting that is problematic is the TX buffer size. If it's too small you will enjoy low latency, but the trade-off will be much looser filter edges and ingress into the opposite sideband along with a tendency to suffer from audio dropouts. So... when you couple over-driven audio stages along with poor buffer settings and then add in a DSP filter with a low frequency TX cutoff of "0" it's a recipe for horrific transmitter performance.

Tune around and you will see quite a few of those signals...

[K1JJ]

Well, I tried all the changes including new firmware and still have the spike. I will try new PSDR next.

New info: On AM,  I listened to the PTT unkey  on a RX and hear a short beep up 2kc from the carrier freq.  If I am on 3800, then when I unkey I hear a short carrier beep on 3802.  It's like an offset for 1/2 second that is about the same strength as the carrier. Its strength goes up or down with drive, just like the carrier.

On ssb I don't hear it, but will try some audio in and I bet it's there.

It causes a slight splatter up 3-4 kc on unkey and seems to have a fast attack.

This seems software related from sequencing and an offset generated. It does not appear to be what I thought, which was some kind of transient that wud have a harsh arcing sound. This is a clear CW note.


It sounds exactly like a roger beep, but up 2kc from center freq! I will try new PSDR from the site and see.

Hmmmm. I hope its not related to computer latency.. or maybe I do.
T

[K1JJ]

More info:

Ran the latency program and it said I may have some drivers that are behaving badly - to disable them one at a time.  Will try that.

Also found the spike is there whether the CPU is at 12% or 78%, no effect. So guess the spike is not caused by latency.

I do not hear a beep on ssb with audio tone going in, just a pop from the spike. On AM it's a roger beep.

T

[KC2ZFA]

a question for those in the know:

is latency LESS of an issue with machines running unix/linux ?

Peter

[Pete, WA2CWA]

a question for those in the know:

is latency LESS of an issue with machines running unix/linux ?

Peter

It depends on whether you're running background processes or the machine is running background processes.

[WA1GFZ]

Tom,
I just don't know because I'm still using the mouse to key the rig. I think you have a Joe version of mercury so not sure if that is an issue. I'm running the same penny software as you. My guess is the rig isn't broken. Also I find the internal audio processing pretty good if you want to try some addioional compression. I have beads on audio lead and usb lead.
My EQ is set to minimum on the main slider with mic gain at 10. Compression at 13. Direct mic into rig. BTW guys I had SSB minimum frequency at 0 so may change that. Rob didn't complain so didn't change it. 

[W1AEX]

a question for those in the know:

is latency LESS of an issue with machines running unix/linux ?

Peter

Peter: 

I'm not sure that I qualify as someone in the know, but a few variations of this question have appeared in the Flex reflectors. The responses from several Flex representatives indicated that no matter how fast the computer is, or how lean the OS is, there will always be latency due to the digital processing taking place in "real time". There's a lot of signal processing going on throughout the transmitter chain. With the hardware currently available many users would probably not find it objectionable. On my 6 year-old PC it is definitely there when I monitor my signal and various DPC latency utilities indicate that it's in the 100ms - 200ms range. Most of the latency complaints seem to be coming from the CW guys who work break-in rather than the phone operators who want to monitor themselves.

Frank:  I didn't see any energy at all in the opposite sideband when we were messing around on 3870. Your signal looked very clean.

Rob W1AEX  

[K1JJ]

Rob, is yours a single core?   What CPU % does it run at when the waterfall is on?

Excuse me if my terminology is not correct, but I think much of the problem is that PSDR needs to run under an OS, namely, Windows. For example, I have a telescope tracking program that controls stepper motors. It can run flawlessly under DOS with an old 386 computer without a stutter. But when using a new Pentium running under Windows, the steppers miss steps and stagger/false  terribly. Thus, the designer recommends to find an older computer that will run DOS.  Windows is a CPU task hog.

BTW, this same telescope programmer has a second product that does away with the stepper control and uses stand-alone servo motors that then take their positions  from a Windows based astro sky program. Works fine under Windows cuz it doesn't need constant real time tasking.  As long as the software doesn't need real time or close to real time interuptions, it's fine with Windows.  

That's why I think the day will come when we do away with the computer for intensive calculation threads and rely more on a self contained set of chips. The computer could be used for more lax data management and screen interfacing.

T

[W1AEX]

Rob, is yours a single core?   What CPU % does it run at when the waterfall is on?

Yes, it is a single core Pentium 4 (3.0g) with 1 gig of ram. It will typically run between 18% - 24% when PowerSDR is reduced to its smallest screen size. If I stretch PowerSDR all the way across the screen then CPU utilization will climb into the 30% - 40% range. The size of the spectrum display has a major impact on how hard the computer has to work to draw the fast-changing graphics.

The attached picture shows my CPU utilization, and also shows a really ratty signal in the spectrum display. Pretty nasty looking sideband suppression eh? The vertical lines in the spectrum display represent 1 kc per division so when you do the math it looks like 7 kc on lower side and 5 kc on the upper side for a whopping 12 kc single sideband signal!

[K1JJ]

Yay!  One down with one to go...

Looks like Rob was correct.  I downloaded the KD5TDF PSDR and the CPU is at 20% with the band scope running. No stutters.   My computer is just too slow to handle the diversity. Joe says the KD5 uses less threads running together so is better for my single core for now.  

Either way, I will need a 4-core in a few weeks when I add the 2nd Merc receiver.

However, the spike is still there. Still working on that.

T

[WA1GFZ]

Tom,
I was just looking at the Metis manual and they say you can send PTT into OZY and Metis duplicated the function. Also your keyer goes directly into ozy. Maybe that is worth a try. Maybe the data bus is better set up if PTT goes into the hub rather than the arm. There may be a timing issue. You might ask further up the food chain.

[WA1GFZ]

Tom,
I have not upgraded power sdr in a while. what version is it and where did you get it? I think I have the latest svn download but have not tried it yet.
I need to study metis manual to see how much work it will be to integrate.
I'm not going to make any changes until I see what I need to do to integrate the new board.