search

EngineerGuy314 / pico-WSPRer

Minimalist WSPR tracker for pico-balloons utilizing Raspberry Pi Pico (or Rp2040) as the RF generator (aka The Cheapest Tracker In The World™). More info: [WIKI](https://github.com/EngineerGuy314/pico-WSPRer/wiki/pico%E2%80%90WSPRer-(aka-Cheapest-Tracker-in-the-World%E2%84%A2))
MIT License
43 stars 9 forks source link

RFOUT_Pin dead - what happens with inverted PIN_7 ?? #5

Closed whallmann closed 6 months ago

whallmann commented 6 months ago

Hi, after some test hours the RFOUT_PIN 6 seams to be dead. The Signal is jumping around the band and isnt any longer on the defined one. So i had this earlier during experiments and simply changed the PIN to the next higher Pin. This worked very well. But now i see in the description that the PIN7 will be also output a inverted Signal. But th ere is no DEFINE for this.

Some Questions:

Lot of questions ;-) sorry Thanks Wolf DF7PN

serych commented 6 months ago

It is using PIO state machines in RP2040. You can find the assembler code in /hf-oscilator/piodco/dco2.pio file. As far as I understand the code instructions: set pins, 1 (line 77 and 87) are sending to the two consecutive pins (i.e. 6 and 7) values b01, instructions: set pins, 2 (line 82 and 92) are sending values b10. So the whole block of code creates two periods of phase shifted signals on the two pins. It is similar principle which is usualy used with Si 5351 chip. You can connect the dipole to the two pins or only one of them and ground, but it means, that the signal will be half in the strength.

73! Jakub, OK1SE

From: Antennen-Wolfgang @.> Sent: Tuesday, April 23, 2024 11:57 AM To: EngineerGuy314/pico-WSPRer @.> Cc: Subscribed @.***> Subject: [EngineerGuy314/pico-WSPRer] RFOUT_Pin dead - what happens with inverted PIN_7 ?? (Issue #5)

Hi, after some test hours the RFOUT_PIN 6 seams to be dead. The Signal is jumping around the band and isnt any longer on the defined one. So i had this earlier during experiments and simply changed the PIN to the next higher Pin. This worked very well. But now i see in the description that the PIN7 will be also output a inverted Signal. But th ere is no DEFINE for this.

Some Questions:

Lot of questions ;-) sorry Thanks Wolf DF7PN

— Reply to this email directly, view it on GitHubhttps://github.com/EngineerGuy314/pico-WSPRer/issues/5, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCVHZEYECXQRAJYJ65E3B3Y6YV5HAVCNFSM6AAAAABGURPWA2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TQNBVGE2DMNI. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

sivaelid commented 6 months ago

Hi Wallmann
I hope the following will help.

I suspect that Rob will comment as well.

I have been in discussion with him over the last few weeks with tweeks and comments and has been briliant at responding. The issues you highlight were ones I had seen for a good while but only yesterday I solved. I had the output solid for arround 20 second every transmission but then it jumped form 14.097MHz to arround 13Mhz. Yesterday I found in my case that the Print statements in GPS time were upsetting the value of the corrrection value PPB and showing very high values of 15 digits when the unit was failling compared to a normal situation which is arround 7 digits correction

Rob has made some improvement in the latest version so you can disable some of the Print Statements. Set the " #define d_enable_all_debugging_messages" to NO from YES iand recompile. This will stop the debug mesages. It worked on both my Sample units I have. These are stable and working well sending WSPR messages. I would note that the PI PICO is not designed as an RF transmitter and so can be susectable to connections and lead lenghts. I did find on one build it was unstable from RF but then I have have loads of long wires conected

Rob Has also made a few other corrections on user interface so you do not need the FET to cut of GPS when configuring the user interface to work. This alos works well.

This is a briliant project that Rob has done. I hope it all works for you now. All the Best 73 Simon G8HAM

whallmann commented 6 months ago

Hi Wallmann I hope the following will help.

I suspect that Rob will comment as well.

I have been in discussion with him over the last few weeks with tweeks and comments and has been briliant at responding. The issues you highlight were ones I had seen for a good while but only yesterday I solved. I had the output solid for arround 20 second every transmission but then it jumped form 14.097MHz to arround 13Mhz. Yesterday I found in my case that the Print statements in GPS time were upsetting the value of the corrrection value PPB and showing very high values of 15 digits when the unit was failling compared to a normal situation which is arround 7 digits correction

Rob has made some improvement in the latest version so you can disable some of the Print Statements. Set the " #define d_enable_all_debugging_messages" to NO from YES iand recompile. This will stop the debug mesages. It worked on both my Sample units I have. These are stable and working well sending WSPR messages. I would note that the PI PICO is not designed as an RF transmitter and so can be susectable to connections and lead lenghts. I did find on one build it was unstable from RF but then I have have loads of long wires conected

Rob Has also made a few other corrections on user interface so you do not need the FET to cut of GPS when configuring the user interface to work. This alos works well.

This is a briliant project that Rob has done. I hope it all works for you now. All the Best 73 Simon G8HAM

Thanks Simon yes its a really great work this project and its going to get better than ever.

I will have an eye on your ideas and next releases.

cu 73 Wolf

whallmann commented 6 months ago

Hi Jakub thanks for trying to explain how this work, but unfortunelly i am am not able to understand this fully.

It is using PIO state machines in RP2040. You can find the assembler code in /hf-oscilator/piodco/dco2.pio file. As far as I understand the code instructions: set pins, 1 (line 77 and 87) are sending to the two consecutive pins (i.e. 6 and 7) values b01, instructions: set pins, 2 (line 82 and 92) are sending values b10. So the whole block of code creates two periods of phase shifted signals on the two pins. It is similar principle which is usualy used with Si 5351 chip.

You can connect the dipole to the two pins or only one of them and ground, but it means, that the signal will be half in the strength.

ok you suggest to use both legs of the dipol on the pin6 and 7 to get more power out.
After a damage of RFPIN 6 i changed in software to 8 and soldered also to nbr 8. So i hope pin 7 is still working and i solder the second dipol leg to nbr 7

hope this works as designed.

73 Wolf

EngineerGuy314 commented 6 months ago

You can connect the dipole to the two pins or only one of them and ground, but it means, that the signal will be half in the strength.

Yes, that is true. Unfortunately it was kindof a hack job when i added the antiphase output on pin 7. The changes were hardcoded. If you change the defined pin from 6 to 8 for instance, I think you will get just single phase output on 8, and nothing on 7.

To keep the code efficient, the two RF output pins must be adjacent. But I can make a code change so that if you change the pin definition from 6 to 8 for instance, it will shift the anti-phase output to 9. I will keep this issue open until i make that change. Thank you for all the testing and comments!

EngineerGuy314 commented 6 months ago

I had the output solid for arround 20 second every transmission but then it jumped form 14.097MHz to arround 13Mhz.

I saw this behavior early on for a while, and Simon was plagued with it more recently. It went away for him when i reduced the print statements.

I suspect this kind of weird thing can also be caused by long wire leads (ie, pico and gps several inches apart of connected on a breadboard). If nothing else works, try to glue and solder the gps directly to the pico as in my pictures and remove any extra wires. There is RF energy flying all over the place and nothing special in the board layout to keep that RF out of places it doesn't belong!

EngineerGuy314 commented 6 months ago

no more 0.1uF condenser and no remarks to low-pass-filter. Are they not nesessary any longer?

thats a touchy question. they were never "necessary", as in it will work without any filter. In my testing, because the antenna is resonant at my desired frequency, the amount of RF thats actually radiated out of the pass band is negligible.

The FCC has some verbage about harmonics being 46dB less than the fundamental or something like that. But that spec was created to be applied to 1500 watt transmitters. 46dB less than 1500watt is still orders of magnitude more than the total power output here.

EngineerGuy314 commented 6 months ago

If you change the defined pin from 6 to 8 for instance, I think you will get just single phase output on 8, and nothing on 7.

Actually, I take that back. My code change wasn't that sloppy after all, and I just confirmed with some tests.

If you change the defined pin to 7, then you will get RF on pin 7 and 8. If you change the definition to 8, you get RF on pin 8 and 9, (those are the only combinations i tested, but it should theoretically work on any two adjacently numbered GPIO)

whallmann commented 6 months ago

Great - i am happy with the pin assignment you last described. Will test ist. But i also saw one transmission much higher then 14.097 - so this gets normal after some transmissions - was with deactivated stamp-lines. So many thanks for your time and work !!!