piHPSDR LOCALCW

[bi...@palomar.pl]

Hi,

Is the information on this page regarding CW up to date?
https://github.com/pa3gsb/Radioberry-2.x/wiki/piHPSDR-running-CW-mode

I ask because it looks completely different on mine:

I have connected paddle key to pin 5 and 6 and now I need to set the GPIO pins.
How do you have Paddle CW running on 5 and 6 pins?

[Mario Vano]

I'm seeing exactly the same behavior - the dialog is broken and if I close it and try to start the program, it doesn't work right - even after rebooting. There's no reception and a bright line down the center of the spectrum.

If I answer no when installing, however. the program works right but doesn't seem to support CW.

M

[bi...@palomar.pl]

Thanks Mario for the reply. I have the same problem (GPIO cw not supported and rx not working then). At the moment I have come to the conclusion that I will give up on doing it using GPIO and use the method via MIDI (done on Teensy  microcontroller  -  Christoph DL1YCF way). 

Anybody use Radioberry with CW here?

Best73

Jarek SQ1RES

[Yado-san]

Hi Jarek, 

I think you are right that your MIDI interface is one of the right choices.

My recommendation is to use an external keyer with sidetone; connect it to key (Pin14) on RB2.
 https://groups.google.com/g/radioberry/c/9CeXFsSQZFE/m/Ebf8FfpeAAAJ

The WiKi info is for GateWare (72.2 - 73.0), and pihpsdr before Aug 2021.
Around Aug 2021, the GPIOs were changed in an update to g0orx/pihpsdr. Also, pihpsdr has not been updated since Jan,2022.
And dl1ycf/pihpsdr does not support RB2.

Therefore, to use the CW keyer of pihpsdr, you need to build pihpsdr by yourself or propose a modified specification to dl1ycf.


This is a g0orx/pihpsdr, but it is possible to try the keyer function of a pihpsdr that Johan has modified and pull-requested.
  https://groups.google.com/g/radioberry/c/Q1AmOpy2Ok4/m/J1MVvo_EBwAJ
  https://groups.google.com/g/radioberry/c/Q1AmOpy2Ok4/m/b_Z4XEobCAAJ

The HL2 has no mechanism to generate a keyer and tone as the HL2 is designed to be put in a backroom somewhere and operated remotely. nor RB2.
I wanted to try to use the RB2 to be a portable transceiver, so I modified the FPGA to have a keyer and sidetone built into it.( I am not currently using this.)
  https://github.com/hish8612/Hermes-Lite2/blob/master/gateware/variants/radioberry_cl025_cwsidetone/Radioberry2_cwsidetone_1.pdf


FYI:

HL2 and CW Keyer Function
  https://groups.google.com/g/hermes-lite/c/CnqO2wi1m-4/m/ZzBxK46hCQAJ
Low Latency CW Sidetone
  https://groups.google.com/g/hermes-lite/c/P-i_EYCN--k/m/E_1i7smsAgAJ
Thetis Beta 6 from Reid / MI0BOT cmASIO
  https://groups.google.com/g/radioberry/c/OdsUC5vcjM0/m/tcdeot7wAwAJ

softerhardware CWKeyer
  https://github.com/softerhardware/CWKeyer
dl1ycf TeensyWinkeyEmulator
  https://github.com/dl1ycf/TeensyWinkeyEmulator

Yado-san,jg1twp
 

2025年1月23日木曜日 18:58:37 UTC+9 bi...@palomar.pl:

[Mario Vano]

If I connect a key between pin14 on CN301 and ground and set piHPSDR to CW mode, it appears to send CW properly. Has anyone confirmed that this is correct and provides clean keying on the air?

Some time ago, I wrote a primitive standalone python keyer and started using it with Quisk on my own Pi Radio hardware platform. It seems to work well in that case (but Quisk provides a sidetone).

It reads GPIO inputs for the paddle and straight key and outputs to another GPIO pin. I can try modifying it to use the RadioBerry unused GPIO pins and  jumpering the output pin with a soldered yellow wire to pin 14.

This may work OK if it gets enough CPU time away from the gateway to have clean keying. It works great with Quisk and a my softrock style radio, but may run into trouble on RadioBerry.

This only leaves the problem of monitoring. I suppose I can try to put some code in it to output PWM to an additional pin if there are any free.

If anyone else is interested in playing with this approach, here's a link to my python code on github...

https://github.com/mpvano/radiohat2/blob/main/libradiohat/TESTS/pikeyer1.py

If you decide to try this out, don't forget that the existing GPIO assignments in that version have conflicts with RadioBerry and need to be changed.

I'll try to report back if I have any luck at all...

M

[bi...@palomar.pl]

Thank you, Yado-san for this comprehensive set of information. In fact, I was also considering using pin 14 and an external keyer w/sidetone (like @ Hermes Lite2) but only consider this as a last resort if MIDI didn't work as I expected for CW work.

Best73
Jarek SQ1RES

[SNAIL]

Joined with same problem.

[bi...@palomar.pl]

SNAIL, to be honest I've finally abandoned the idea of ​​using pins 5 and 6. I've already ordered a teensy controller to program it and use it as MIDI. While waiting for delivery I check how the solution with pin 14 and external keyer works. Well, it's not bad. "CW Break In - Delay (ms)" setting works in the menu - CW. The only downside is the lack of sidetone, but it can be easy solved in various ways.

Vy73

Jarek SQ1RES

[SNAIL]

Ok I'm using mostly straight key CW, only sometimes do use keyer but in my young years, I worked as electronic engineer at "flying pencils" plant and I was taught that if the manual from the designer said it should be this way and that way, then that’s the only way it should be.

And I want to have same option as it on the screenshot.

[Mario Vano]

OK Folks, Don't get too excited, but I think I might the piHPSDR built in keyer working without any additional hardware...

I had to give up on my python keyer idea because it appears that some of the radioberry documentation is incorrect about what GPIO lines are still free and the python keyer needs at least 3 lines, so I explored fixing the latest version of piHPSDR at github instead.

At the moment, there are only TWO unused GPIO lines available. These are the ones normally reserved for use by the Pi console serial port. If that option is turned off, they can be used for the keyer left and right keys.

These are on the following GPIO lines: on pins 7 and 8 of the GPIO card:

    CWR_LINE = 14;

    CWL_LINE = 4;

Unfortunately, they are not available from the Radioberry OC connector and you must carefully solder wires to the back of the GPIO connector itself to connect them to your key jack.

The reason that the existing dialog cannot be used to set these IO pins is that the setup for the dialog clobbers the driver's GPIO pins when it checks pin availability and the driver crashes. To fix this problem, I hard coded the needed definitions into the source file called "gpio.c"

There's a section there for use with no ui controller. It's very important that "no controller" be selected when selecting the device at startup.

If you look at the source file, around line 967 you will find a case in a switch statement for NO_CONTROLLER.

I made it look like this and built pihpsdr:

case NO_CONTROLLER:

  default:

    //

    // GPIO lines that are not used elsewhere: 5,  6, 12, 16,

    //                                        22, 23, 24, 25, 27

    //

    CWR_LINE = 14;

    CWL_LINE = 4;

//    CWL_LINE = 5;

//    CWR_LINE = 6;

//    CWKEY_LINE = 12;

//    PTTIN_LINE = 16;

//    PTTOUT_LINE = 22;

    CWOUT_LINE = 15;

    memcpy(my_encoders, encoders_no_controller, sizeof(my_encoders));

    memcpy(my_switches, switches_no_controller, sizeof(my_switches));

    encoders = my_encoders;

    switches = my_switches;

    break;

I commented out the old lines and left them in place to help in locating them.

I used the following build options (in the file called "make.config.pihpsdr"

TCI=OFF

GPIO=ON

MIDI=ON

SATURN=OFF

USBOZY=OFF

SOAPYSDR=OFF

STEMLAB=OFF

SERVER=OFF

AUDIO=ALSA

Once the program is built you will have to reset all your preferences; when you do make sure to uncheck "CW handled in radio"

this appears to work fine here, but it's highly experimental. Don't try this unless you know your way around github and C programming.

I can't provide any help or binaries, since I have to do other patches to run my non-standard Low pass filter card.

If this experiment seems to be working out, perhaps we can come up with a better patch that can be submitted to the repository.

Also, it would be great if the FPGA could be modified by someone to pass these pins through to the radioberry's own IO connector instead of the ones that don't work!

Let me know if you have any success with this...

73

AE0GL, Mario

[Yado-san]

Hi Mario,

Great job!
 by the way, how about if set CWL_LINE=17 and CWR_LINE=21 ?
fyr.
 https://groups.google.com/g/radioberry/c/N54JWxbkq0o/m/sMZvgLVhCAAJ

Tnx! Yado-san, jg1twp

2025年2月9日日曜日 10:37:33 UTC+9 Mario Vano:

[Mario Vano]

Better hold off! Paul says he has fixed Both the FPGA and piHPSDR. I think he's still debugging, but looks like when he is all done, no patching or wiring workarounds may be needed!

[bi...@palomar.pl]

Mario, this is great news!!

Vy73! Jarek SQ1RES

[Mario Vano]

Oh, Damn - this is confusing: It looks like the message from Paul somebody sent me saying he was working on it is a false alarm! It's an old message from years ago! He still is not involved in this mess.

I think we still need my work around or something like it. Sorry to speak too soon.

In reply to Yado-san, - No other pins are available than the two I used! You sent me a link to a stale message. The FPGA is still not copying pins through as documented.

I'm looking into finding a fix for the FPGA, but I'm really out of my depth!

sorry for adding even more confusion. To repeat - As of today, my fixes are STILL needed for the keyer to work.

M

[pa3gsb]

Hi guys,

The https://github.com/pa3gsb/Radioberry-2.x/wiki/piHPSDR-running-CW-mode  shows the implementation based on the John Melton pihpsdr software from long time ago.

This functionality as showed for selection is removed on 8 dec 2020 when he moved away from wiringpi to libgpio.

 

For the radioberry there are many configurations possible.

I think for people who wants to run CW and pihpsdr look to the git repo of Christoph van W¨ullen, DL1YCF.

https://github.com/dl1ycf/pihpsdr/releases/download/v2.3/piHPSDR-Manual.pdf

Hope this gives some new ideas.

73 Johan

PA3GSB

Op maandag 10 februari 2025 om 16:37:39 UTC+1 schreef mpv...@gmail.com:

[Mario Vano]

I think we are going in circles here.

I think there is no reason why we can't use the hardwire keyer except that it must not poll any other pins at startup or it will break the driver.

I've demonstrated here that the only obstacle is that there are no longer any pass through pins from the radioberry board to the Pi GPIO as there once were.

If I connect to the GPIO UART pins on the pi directly with the key and instruct piHPSDR to use those pins during the build then the keyer works properly.

what we need is a new build of the FPGA that passes through the second pin to avoid having to solder directly to the board (since the radioberry as built does not pass gpio pins through the connector.

I'm not interested in solutions requiring another piece of MIDI hardware, only in getting the board back to working as it appears to be intended and documented. My fix seems to do this.

What seems to be the problem with fixing the broken pin on the gate array? It appears that what is broken is that the FPGA passes CWR through from CN301 to pi pin 33 (GPIO 13) which seems to be in use during data transfers. CWL appears to be OK, but it doesn't appear to be connected from CN301 for some reason either.

I don't understand? I have this working here. All that is needed is a fairly trivial change to the FPGA. What ama I missing?

M

[Mario Vano]

I think I see why it can't be fixed: It looks like the FPGA does not have any physical connections to pin 8 on the GPIO header. It looks like the only way to have this work is the way that I did it. I also don't understand why I don't see any activity on pin 7. It must only be used during loading or something. The wiki shows pin 7 as being pi_tx_clk, but it's not clear what that's for.

I'll keep studying this and testing my fix.

M

[Mario Vano]

Sorry to keep answering myself, but I'm learning more about this as I go.

Pin 7 was apparently used as an input  to provide a 10Mhz clock from the Pi to allow full duplex operation. According to a readme in the repository, this is no longer needed nor functional. However, I've been mulling over the verilog and it looks to me like there's still some processing of this input going on that may come back to bite us later. I need to try to figure out what else looks at the signals derived from it, but the editor in the Intel Quartus IDE is horrible and can't do multi-file searches...

I'll keep you posted if I learn any more.

M

[Yado-san]

Hi Mario, Group

I made a connection table to clarify the GPIO pin connection relationship between Radioberry-2 and RPi4.
dl1ycf/pihpsdr's GPIO table was also included in the table.

The FPGA pins (GPIO pins) for paddle output are different between GW73.0 and 73.2 or later. (i posted)

Also, pihpsdr has changed gpio function.
This may have caused some confusion.

According to this table,  the keyer with built-in dl1ycf/pihpsdr may work if  change gpio.c to the following.( with the latest RB2-GW73.3, )

--- gpio.c - line.967 --

case NO_CONTROLLER:
  default:
    //
    // GPIO lines that are not used elsewhere: 5,  6, 12, 16,
    //                                        22, 23, 24, 25, 27
    //

    CWL_LINE = 17;     // for RB2
    CWR_LINE = 21;
    CWKEY_LINE = -1;
    PTTIN_LINE = -1;
    PTTOUT_LINE = -1;
　CWOUT_LINE = -1;
--- gpio.c ---

Yado-san, jg1twp

2025年2月11日火曜日 10:15:51 UTC+9 Mario Vano:

[Mario Vano]

Thank you Yado-san for doing some additional work on this.

I based my conclusions about pin availability on putting an oscilloscope on the proposed pins and discovering that they were in use by the driver software. I'm currently investigating the FPGA verilog code as a possibly more reliable indicator of what's going on.

When I get a chance (probably not today), I'll see if your proposed pins are viable. If if find any issues, I'll report back.

I do understand that the gateware changed the use of these chips. That's what makes the uart input and output pins viable now. In older gateware, pin 7 was used for a 10mhz clock coming in from the pi - which the gateware no longer uses. I'm investigating right now whether some side effects may occur related to this input (even though it's no longer in use). I think it was being used to run a couple of "cleanup" timers during the transition between transmitting and receiving. Those timers may still get reset after a a few million glitches from keying contacts.

Which version of the gateware is the current default installation when the scripts from the Wiki are run? In the intel IDE I'm looking at the latest one I could find in the "releases folder". Unfortunately, it's hard to tell which gateware sources matter since it's not built from the Makefile as most people don't have Intel simulation software.

Are we having fun yet?

M

[Yado-san]

It's great! 

The current default installation gateware version is 73.3.

- The gateware version is displayed when you start Radioberry with the command
  $ sudo radioberry
- If you are connected to the Internet, you can also check the GateWare version at Radioberry Overview.
  https://www.pa3gsb.nl/radioberry/api/read.php
- The version is described in the RTL code.
  https://github.com/softerhardware/Hermes-Lite2/blob/master/gateware/rtl/radioberry/radioberry_core.v
  line.63-64  -> VERSION_MAJOR = 8'd73;  _MINOR = 8'd3;

Placed a document on how to compile FPGAs.
https://groups.google.com/g/radioberry/c/cOJO7nmkuWg/m/MVCrhTF6BAAJ

Tnx

Yado-san, jg1twp

2025年2月11日火曜日 23:03:32 UTC+9 Mario Vano:

[Mario Vano]

Thanks - that's a big help in making sure I'm looking at the right version  - I am using Quartus Prime Lite at the moment....

M

[Mario Vano]

I've spent some time reviewing the info you sent and here's what I understand it to mean:

I agree that pi physical pins  8 (GPIO14) and 10 (GPIO 15) are available for the keyer as the Kicad files show them as "no connect"

I believe that Pi physical pin 7 (GPIO 4)  is available for the keyer is at least for the gateware that came with my board.

The reason I believe pin 7 is available is that when I open Radioberry-2.x-master/SBC/rpi-3/fd-firmware/verilog-fpga/radioberry-10CL016 in Quartus and print the pin summary I get the following table (I have added columns for the pi GPIO pin and Kicad connector symbols and a row for the missing pin 55).

It shows nothing connected to pin 55 at all. I do agree that your idea of using GPIO 14 and GPIO 15 makes sense as well. It also indicates that a third pin I was unaware of is available.

For the moment I'll continue to experiment with GPIO 4 and 14, as it seems to be working fine, but when I get a chance I'll try and see if 14 and 15 also work.

Thank you for the info on using Quartus, but I had already gotten that far by myself. I find that Quartus shows a number of errors from that project - but I don't think it matters, since I'm not planning on modifying it - only analyzing it...

I'm enclosing a PDF of the Pin Assignments from Quartus as described above with my added annotations that I used to convince myself that pin 7 was available.

Mario Vano AE0GL

[Yado-san]

Hi Mario and Group,

I have confirmed the operation of the built-in keyer in dl1ycf's pihpsdr on the actual device tonight.

The changes are the same as in the previous my post. (gpio.c / CWL_LINE = 17, CWR_LINE = 21)
No soldering or HDL-modifications are needed.

I have had sidetone delay problems with pihpsdr until now.
I found that compiling with AUDIO=ALSA improves this problem. VY FB :)

* Paddle connections

* Compile dl1ycf's pihpsdr  (if you have already installed pihpsdr with RB2-GW73.2 or later)

see detail,
 https://github.com/dl1ycf/pihpsdr/releases/download/v2.3/piHPSDR-Manual.pdf
  Appendix E Attaching Morse Keys or Paddles
  Appendix G Compile-time options
  Appendix H GPIO Lines for Controllers

$ git clone https://github.com/dl1ycf/pihpsdr.git
$ cd pihpsdr
$ cp Makefile GNUmakefile
$ vi GNUmakefile  // Edit compile-time options

  TCI=OFF
  GPIO=ON
  MIDI=ON
  SATURN=OFF
  USBOZY=OFF
  SOAPYSDR=OFF
  STEMLAB=OFF

  AUDIO=ALSA

$ cd src
$ vi gpio.c   // Edit 'case NO_CONTROLLER' , line 973-
    CWL_LINE = 17;    // RB2 keyer_CWL: GPIO17, fpga pin.113
    CWR_LINE = 21;    // RB2 keyer_CWR: GPIO21, fpga pin.42
    CWKEY_LINE = -1;    // RB2, Not available
    PTTIN_LINE = -1;    // RB2, Not available
    PTTOUT_LINE = -1;   // RB2, Not available
　CWOUT_LINE = -1;    // RB2, Not available

$ cd ..
$ make clean
$ make

* Notes

-Select 'No Controller'

-Uncheck 'CW handed in Radio'

-Compile option, AUDIO=PULSE : Sidetone delay is too large to use.

-Compile option, AUDIO=ALSA  : No sound coming out of headphone jack on RPi4B. Sidetone delay is fine.

 (using USB Audio)   I don't know why the ALSA and PULSE assignments make a difference.

//

Yadi-san, jg1twp

2025年2月13日木曜日 2:16:53 UTC+9 Mario Vano:

[Mario Vano]

Wow! That looks great! I can't wait to give it a try, since the cabling is much simpler.

I find that ALSA is much lower latency and more stable as well...

Does this mean that  all we need to do is submit a pull request for the change to "no controller" in the official piHPSDR github? That way it would work for everyone who just installs from the simple scripts...

thanks!

M

[pa3gsb]

Yado-san,

GREAT work. 

I think we will need to contact Christoph DL1YCF to make get it in the main stream of pihpsdr. 

73 Johan

PA3GSB 

Op donderdag 13 februari 2025 om 15:00:19 UTC+1 schreef Yado-san:

[Mario Vano]

Hi Yado-san, Johan et al...

I've confirmed Yyado-san's work. It works perfectly here as well. I'm sure it's the right solution...

Great job!

M

[Yado-san]

Thanks for confirming that it works.

With ALSA, can key at 30 WPM or higher while listening to the built-in sidetone. (I can't do CW QSO so fast, Hi :)
and I asked ChatGPT about ALSA and PULSE.

* Correction to the connection, the KEY input is CN301-pin14, and pin13 is PTT.
(Straight key on pin14 can be used when pihpsdr is compiled with GPIO=OFF or LOCALlCW=No.)

Thanks again to the developers of the pihpsdr! John Melton(G0ORX), Christoph van Wüllen(DL1YCF)...

Yado-san, jg1twp

2025年2月14日金曜日 6:52:26 UTC+9 Mario Vano:

[pa3gsb]

Please be carefull with the connection to CN301 : The pins are directly connected to the FPGA.

This includes the CW connections.

In the FPGA code the pins are using a weak up resistor:

set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to io_phone_ring
set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to io_phone_tip

Furthermore you have the possibity to place the following resistores for better pull up; higher speed.

 

HL-2 uses this circuit:

Just to inform you to be carefull with your RB radio!

73 Johan

PA3GSB

Op vrijdag 14 februari 2025 om 13:18:03 UTC+1 schreef Yado-san:

[SNAIL]

Just to inform all that Yado-san corrections GPIO.C file already made by Christoph. Tested. Working.

Thanks all for contribution.