Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
WSPR on 28MHz
|
g3zjo
Hi Hans
I tried various setting of the calibration, clutching at straws again, Andy FTDbhas negative values ie. 124,999,xxx mine is 125,000,555 there was no improvement in the narrow 3 Unit WSPR outputted. I have tried extra decoupling of the DC supply at the DDS pins, no difference. I have eliminated any possibility of the Output stage feeding back to the generator circuit by removing the LPF and the supply to the output devices. I am now just using the DDS Module output. Measurements of the output 'Square wave' which is actually sine I think the module is rated for square wave use only to 1MHz from memory. TX'ing WSPR :- 18.126100MHz - 7.0V pp, 19.126100MHz - 6.5V pp, 20.126100, 21.126100MHz - 6.0V pp, 22.126100MHz - 22.126100MHz By the time it get to 28MHz it is around 4.0Vpp but I think this is irrelevant, what is happening to the signal generation process is more relevant. I stopped the measurement here because the fold over point is between 21MHz and 22MHz. At 21.126200MHz WSPR normal height and 4 Unit WSPR which decodes is generated. At 22.126100MHz the 'fold over has taken place' the 4th data Unit frequency is absent, I don't think it is an overall compression of the data shift. Attached and destined for my Files Folder is a Capture which clearly shows a normal transmission at 21MHz followed by a cramped one at 22MHz. The Grab is straight from the screen in real time no cutting pasting etc. has been done so the results are obvious. Clearly something is happening at this point in the code, arithmetic error or whatever. Posted to the Group. Please how many Ultimate 2's are there that are OK on 21, 24 or28MHz, there do seem to be some reports from users. Can someone confirm the above 'fold over point'. We need more facts for Hans to investigate the problem. Andy FTD your requested Set Up Mode........Just press the Left button whilst WSPR is being sent, it goes into Sig Gen Mode like at the end of the 21MHz Trace in the Att.. 73 Eddie G3ZJO |
|
"Philip"
Did a couple of hours test on WSPR 28MHz earlier
toggle quoted message
Show quoted text
Got a few spots which considering the band conditions and my Windom's reluctance to tune on 10 meters was a result.. The PA FET gets hot on this higher band though....much too hot.. Not bothered by this as my second kit will be boxed with the DDR feeding a different PA altogether and I will be loosing the FET stage. Anyhoo, it got out... Screen grab here... Philip G4JVF --- In QRPLabs@..., g3zjo <g3zjo@...> wrote:
|
|
g3zjo
On 18/05/2013 20:16, Philip wrote:
Did a couple of hours test on WSPR 28MHz earlier Thanks Philip Glad yours works on 28MHz, knowing that you use outboard LPF was an influence for my test without the Output FET powered in case there was feedback. Your report puts us back into confusion but we love the challenge really don't we. 73 Eddie G3ZJO |
|
g3zjo
Further update on this problem.
G0FTD seems to have intermittent thin WSPR data trace and no de-codes on 28MHz but has seen a decode or 2 of his own signal after fiddling. My unit is absolutely consistent with its performance. Further tests here and measurements reveal that that WSPR Data spacing is totally wrong. At 7.00MHz the difference between tone 0 and tone 3 is 10Hz this decodes because of WSPR's tolerance, as we increase the frequency the tone spacing gets smaller, I am not sure yet where it gets about right but after 21MHz it has got too small for it to de-code. At 28MHz it is down to around 4Hz the WSPR data is all there but its noticeable that Data 3 occupies the Data2 frequency. If the frequency shift variation is linear, let us assume it is, then:- 7MHz = 10Hz 10.5MHz = 9Hz 14MHz = 8Hz 21MHz = 6Hz 22 MHz = <6Hz 28MHz = 4Hz If I had not already established the point where decodes fail it could be predicted from the table above, when the spacing is less than 6Hz ie 22MHz. Additionally the only frequency where it is right is 21MHz. Tomorrow I will check the theory by measuring at 21MHz. Eddie G3ZJO |
|
Hans Summers
Hi Eddie Many thanks for all your efforts in helping to collect evidence to track down this problem. I know it might be a little frustrating but thanks for persisting!
I suspect that there might be some arithmetic issue in my code which reduces the accuracy of the calculation when the frequency is high. More specifically, when the shift frequency becomes smaller relative to the baseline output frequency.
If you have time, I think that a very useful test might be a ramp from 0 to 5,5Hz shift (say), at 0.5Hz increments. A staircase, really. This would show very clearly any issues with inaccuracies of the steps, and clarify immediately on what bands and frequencies they started to become a problem.?
I am referring to the stuff in section 8 of the manual (page 28). A customised message to produce a staircase of shifts from 0 to 5.5 Hz, with 5 seconds spent on each stair. The staircase will take 1 minute. This will make it much easier to see what is going on than images of WSPR, which spends only a short time on each frequency so looks messy on the Argo (etc) display.
The required mode should be FSK/CW, and the Message string contains the speed and the shifts, with an asterix ' * ' character to start and end it. So it should be *050123456789AB* for the described ramp.
73 Hans G0UPL On Sat, May 18, 2013 at 11:33 PM, g3zjo <g3zjo@...> wrote:
|
|
Andy Cutland
I have my grabber monitoring my 28mhz wspr output.
toggle quoted message
Show quoted text
www.qsl.net/gj7rwt/gj7rwthomepage.html At 28mhz I seem to have 9hz shift. 73's de Andy GJ7RWT ------------------------------ On Sat, May 18, 2013 4:58 PM PDT Hans Summers wrote:
Hi Eddie |
|
g3zjo
On 19/05/2013 00:58, Hans Summers wrote:
Many thanks for all your efforts in helping to collect evidence to track down this problem. I know it might be a little frustrating but thanks for persisting! The efforts are perverse fun Hans, as long as the information flow is not too great for you. I will do the ramp test later today. We are thinking along the same lines. What I have done this morning is to set FSKCW5 to a 9Hz (Max) shift and run that at the 28MHz WSPR frequency to see if the system is capable of shifting the 6Hz for WSPR or more. This has proved that it is indeed capable and pretty accurate. Thinking also on the generation of WSPR and the V2 problem with the System Clock I wondered if there may be an accuracy problem effecting the arithmetic there. Since the GPS works fine for me I have never worried about setting the System clock. I checked and it was 1.740KHz high, I calibrated accordingly, set GPS to off for good measure, set the time manually and ran WSPR at 7MHz all looked well and it decoded as usual. I then tried 28MHz WSPR and the shift is too small and there are no decodes. So that is another pathway eliminated. BTW consistent with FTD's intermittent shift on 28MHz WSPR it is difficult to say but it may vary over a range over time, I am pretty sure the excessive shift on 7MHz went from 10Hz to 8Hz after a few hours last night. As for Digi WSPR looking messy it is a pity that DDS and WSPRaspberryPi systems can't do a soft slide of frequency shift. Having heard a semi local station yesterday on 28MHz clicking and banging away on WSPR I must say that the incessant spikes are disturbing, even anti social. Does the U2 DDS just change the frequency word for each Data transition, it sounds as if it is going to zero in between. I think that the really bad noise, (hammer on a spade) on 28MHz WSPR though is another manifestation of the bad shift, the tones hitting the ceiling at Data3. 73 Eddie |
|
"andyfoad@..."
--- In QRPLabs@..., Hans Summers <hans.summers@...> wrote:
So it should be *050123456789AB* for the described ramp.I've done the ramp test. Results are here: It only confirms my previous findings :-( 1) At one chosen frequency in 28Mhz I see 4 tones, but they done ramp. The final one goes lower. 2) I then choose another random 28Mhz frequency up about 10Khz (not really counting) and now I get only TWO tones. 3) A third random frequency gives me an even weirder result. Three tones but one look like it's being split up if that makes sense. So it does look like all the observations about not seeing certain bit streams (I'll call them that for now) in WSPR look to be true. I have not exhaustive tests yet but I tried - 30m, I saw four tones that seemed quite ok. Got superb on air results! 17m, I saw three tones. 10m, I saw all sorts of tones depending upon the selected frequency. One other thing I note. I have a frequency counter here which I use to also set up the U1. When that changes frequency, as FSK or WSPR my counter `glides` to the required without any problems. The same cannot be said about the U2. During frequency changes it has trouble keeping steady. A sort of electronic Delirium Tremens, which probably explains the spikes that me and Eddie see on our traces. Hope this helps Hans. 73 de Andy |
|
Hans Summers
Hi Andy Thanks for doing the experiments. But can you confirm pls -? 1) On 10MHz (or some frequency where we think it is working Ok), you should see a ramp which goes from 0Hz shift to 5.5Hz shift, in 12 steps of 0.5Hz height, and 5 seconds duration. Then the cycle should repeat.?
2) So what we should expect to see on 10m is something similar - but you're saying that we don't, we see some number of discrete tones, which seems to depend also on the frequency.?
Is my understanding correct? If so, and particularly given that the tones seem to depend on what frequency you are sending, it seems to imply some sort of numerical precision issue in the arithmetic. Which at least tells me where I need to be looking, in the code, so this is very useful.
Regarding the frequency counter - I went through all this in my testing, and for a while I thought that I had made some mistake in the code etc., the frequency counter looked unstable.?
Yes, in the U1 it will glide. The reason is that in the U1 the frequency shift is kind of generated in an analog way - there is a Pulse Width Modulated output from the processor, which is averaged in a resistor-capacitor integrator, and applied to a varicap diode (reverse-biased LED) to create the frequency shift. The resistor-capacitor averaging makes the frequency SLIDE to its new value, not cut suddenly.
In the U2, the frequency is generated digitally in the DDS. When the frequency is changed, there appears to be a short gap in the output of the DDS while the new frequency is being updated. The gap is very short. But if you are very local, i.e. blasting your receiver from right next to it, then yes, you will hear the click. And see it on Argo. I puzzled over strange frequency counter readings for a while, but I was able to prove conclusively that the frequency counter is only jumping around because of that frequency transition being sudden, not smooth.?
I may be wrong, but my feeling currently is that the "sudden" frequency transitions are not a problem. Yes, you can hear the click when receiving a local transmitter, and yes the frequency counter jumps, and yes it isn't like the smooth glide on the U1. But I don't think any of these things are unexpected, or unreasonable, or unacceptable when it comes to WSPR decodes etc. Furthermore I don't see any way around it anyway!
73 Hans G0UPL On Sun, May 19, 2013 at 9:33 AM, andyfoad@... <andyfoad@...> wrote:
|
|
Hans Summers
Hi Andy, Eddie et al I dug around in the code a bit, to try to understand what is happening, in the context of the various observations and evidence you have collected. I think that I can see how the way the tuning word for the DDS is calculated, may be losing precision the higher the output frequency goes. To imagine it: numerically in the arithmetic calculating the word, a small increment of a fraction of a Hz seems to get lost when trying to be added to the much larger output frequency e.g. 28MHz. The larger the output frequency, the more precision is lost at the other end (fraction of a Hz). I think the good news is that this is just a software problem, not a hardware limitation e.g. a limitation of the DDS module. So it should be fixable.?
The other thing I found is that there is a reset-DDS function being used, to get the DDS ready for receiving serial-mode updates. This function call is made every time the frequency is updated, not just once in the beginning to initialise the DDS module. Clearly it doesn't stop it from working but I think that the effect may be that it is setting the frequency to zero for a brief moment in between the wanted frequency tones - which may be making the frequency transitions more harsh than otherwise needed. I think that this is a minor issue, rather than a show-stopper - but nevertheless I'll try and remove that too.
73 Hans G0UPL On Sun, May 19, 2013 at 11:10 AM, Hans Summers <hans.summers@...> wrote:
|
|
g3zjo
On 19/05/2013 12:53, Hans Summers wrote:
Hi Andy, Eddie et alG3ZJO back on parade, some interesting goings on here, I will do the Ramp Test out of interest but it seems conclusive. Also the results seem so variable depending on frequency, no wonder us poor old boys have been confused. Noteworthy is the opposite results, huge shift with WSPR on 28MHz from Andy RWT. Its good to have as many results as possible. 73 Eddie |
to navigate to use esc to dismiss