afarhan / sbitx Goto Github PK

When I select the mode i.e. CW and set the BW to let say 400Hz > the radio set the 400Hz BW and the label shows 400Hz too.
Now when I switch to USB the radio switches the BW to 3000Hz (widest) but label still shows 400Hz.
On this mode USB I am going to set 2400Hz BW > the radio switches to 2400Hz correctly and label changes to 2400Hz too.
Now when switch back to CW > the radio switched again to 3000Hz (widest) BW and label still shows 2400Hz...

Summarized:

1. When mode is changed > the radio goes always to 3000Hz BW.
2. BW label does not reflect the actual BW after mode switching and staying stuck on last BW value selected.
3. After changing the mode, it does not remember the preview setting with that mode.

So, when we change mode, we save the bw for the previous mode, and restore the bandwidth for the new mode?

Yes... suggestion:
When switching from let say CW (400Hz) to USB we should save 400Hz as last time used BW linked to CW mode and restore the last time used BW on USB for newly selected USB mode.
Of course, all the time any BW can be set on currently selected mode.
Also, the BW label on upper left corner window should always shows actual BW used by radio.

If user will select the mode which was never been used before (after first install or after master reset or so) then my suggestion is to use default 3kHz widest BW for that case until new BW will be set and stored.

short note to my last point:
"If user will select the mode which was never been used before (after first install or after master reset or so) then my suggestion is to use default 3kHz widest BW for that case until new BW will be set and stored."

...maybe the better way is to have preset default values like 400Hz for CW, 2.4kHz for SSB and 3kHz for digi. So if user select any mode for first time (not preview value stored) then these defaults will be used.

I think there is an error in the code in the "sbitx.c" file, in the "sdr_request" function, at approximately line 1358.

This piece of code:

else if (!strcmp(cmd, "tx")){
if (!strcmp(value, "on"))
tr_switch_v2(1);
else
tr_switch_v2(0);
strcpy(response, "ok");

causes that after modifying the transmission activation sequence with the sBitx DE hardware, "tr_switch_v2" is always executed and not "tr_switch_DE". This causes the sBitx DE device to not transmit after the modification.

The correct code should be:

else if (!strcmp(cmd, "tx")){
if (!strcmp(value, "on"))
tr_switch(1);
// tr_switch_v2(1);
else
tr_switch(0);
// tr_switch_v2(0);
strcpy(response, ok");-

When you first start the application, it loads the saved CW Pitch setting. When you key down, the CW carrier is on the VFO frequency. If you change the CW Pitch, the CW carrier moves. For example, with a VFO of 3.550 MHz and a pitch of 600 Hz, when you first start the app, the CW carrier is on 3.550 MHz. If you change the pitch to 800 Hz, the CW carrier is no on 3.550.2 Hz (up 200 Hz). If you exit the app and restart it, the VFO is still 3.550 and the pitch is 800 Hz, but the CW carrier is back on 3.550 MHz.

As I understand things, changing the CW pitch should not change the frequency of the CW carrier, just the sidetone frequency and the frequency of any received signals.

On my sbitx, there are several fields overlayed on each other where the B vfo is displayed.

I think using the tuning knob switch to change the step value is a good idea.

See discussion here on this and related topics.

If you select a CQ that starts with "DX" then the call sign the sBITX assigns "DX" to the call sign box. The issue is the same with any text before the call sign: POTA, SOTA, VOTA, NA, JA, ...

code:

	}
	else
		m3[0];  <<< This statement has no effect. Should it be
//              m3[0] = 0; 
// ???

	return 0;

Suggestion:

Each band has memories for 4 frequencies. There is no obvious way to tell which one is being used.
Add a second line to the band selection buttons indicating which of the memories is being used.

The default label would be a single number or letter.
Allow user to change the label either in the GUI or by manually editing the user settings file.
Example:

Default might be:

[20m]
label0=a
label1=b
label2=c
label3=d

User might customize:

[20m]
freq1=14230000
label1=sstv

real time clock internal board not right.
set 2000/01/01 i have no way to set this can there be an update so it does

jeffrey

The logbook is not logging in contacts.

The code that refers to last_save_at is:

Yet the code never sets it after it does update the file.

This means we write the user settings to disk very, very often, like every time you move the tuning or volume knob.

Adding a line of code to set the variable to now at the end of the function is a fix:

Yet maybe only writing once every 30 seconds is not often enough?

The RTC will (mostly) update the time at startup and be shown on the waterfall but then fails to update and freezes.

The current method (sbitx.c around line 1231) to detect V2 is to call i2cbb_read_i2c_block_data on the address of the power/swr bridge, which fails if it isn't installed as in the DE.

This call prints an error message to the terminal when it fails. If you instead use i2cbb_read_byte_data, it will also fail if the bridge is missing, but won't print the error message.

where are you getting gtk3 for bullseye ? it is not in the pkgs and your binding the build to it

See https://groups.io/g/BITX20/message/106035 and follow-up posts for more details.

Bottom line is if fldigi is not installed the text UI stops responding when you change bands.

This requirement isn't mentioned in install.txt

I suggest that install.txt should include the fixes which are to install and configure fldigi to work with sbitx.

To fix, just do 'sudo apt install fldigi' and in the resulting configuration dialog or configuration menus, set the following key parameters:

  - Operator/Station:  
    Set station and operator callsigns and station locator/location
  - Soundcard(Audio)/Devices
    [X] PortAudio
        Capture:  Loopback: PCM (hw1:1)
        Playback: Loopback: PCM (hw2,0)
  - Rig(Rig Control)/Hamlib
      Rig: Hamlib Net Rigctl (Stable)
      Device: 127.0.0.1:4352
      [X] PTT via Hamlib command

It would be really useful to be able to consistently use a suitable headset, either a USB or a Bluetooth type with the SBITX for phone modes such as SSB especially in a portable operating environment where surrounding noise levels may be particularly high making it difficult to hear the audio out of the radio speaker.
Yes it is possible to use hardwired headphones to solve the speaker audio but there are additional benefits to being able to simply plug in a readily available USB headset or pair with a Bluetooth headset that may be readily available for both audio input as well as output.
Current microphone output into the radio for SSB based on the supplied microphone is too low and requires significant effort to resolve (I am currently working on this solution). Turning the mic gain up raises the noise levels on the audio which degrades the transmitted audio and at low powers audio quality is a significant issue if not right.
I have both types of headset available and happy to help towards testing and implementation of a suitable approach, I am investigating this already but thought it useful to raise via this approach to get help/inspiration

When drive on the sBitx reduced to 18 on 20m, i gewt 5w output. But the RF meter on the rig says 21w - a bit of a difference. I appreciate it may be way down on the list of things to do, but would be nice to get fixed if and when possible.

I had to install libopus using the following command line before build was successful:

'sudo apt install -y libopus-dev'

It might be possible to add it to the build script?

If the update shell script is run and an error occurs with say the git command it goes on to run the build again without any checking.
You might think it has updated when it hasn't.
The fix is to add

set -e

line at the top of the script.
It is always good practice to check return codes in bash scripts.

CW pitch on the display shows only Hz units but value is missing.

The function i2cbb_read_i2c_block_data in file i2cbb.c is possibly missing curly brackets judging by the indentation.

  uint8_t i = 0;
  for (i = 0; i < length - 1; i++) 
  	values[i] = i2c_read_byte(0,0);
	values[i] = i2c_read_byte(1,1);

	i2c_stop_cond();

should this actually be

  uint8_t i = 0;
  for (i = 0; i < length - 1; i++){
  	values[i] = i2c_read_byte(0,0);
	values[i] = i2c_read_byte(1,1);

	i2c_stop_cond();
  }

This seems to change the frequency in 1Mhz steps.
To reproduce: Change step resolution, use the small knob (volume) to rotate through the values. A blank entry is available.

I could not figure out why my RTC was not working correctly (wrong time displayed).
I have found that the preconfigured image did not have NTP installed as per the install.txt

sudo apt install ntp

Now the RTC is working!

static snd_pcm_uframes_t buff_size = 8192; /* Periodsize (bytes) */

  //we allocate enough for two channels of int32_t sized samples	
  data_in = (int32_t *)malloc(buff_size * 2);
  line_out = (int32_t *)malloc(buff_size * 2);
  data_out = (int32_t *)malloc(buff_size * 2);
  input_i = (int32_t *)malloc(sizeof(buff_size * 2);
  output_i = (int32_t *)malloc(sizeof(buff_size * 2);
  input_q = (int32_t *)malloc(sizeof(buff_size * 2);
  output_q = (int32_t *)malloc(sizeof(buff_size * 2);

The comment for buf size says bytes but the allocations are cast to an int32_t* type.
Should each allocation be multiplied by 'sizeof(int32_t)?

During transmitting the power readings on external W-meter is 38W (Drive set to 100) but on the V2 display TX power is flickering between values 0 and 7W during CW keying at 26wpm speed. (only these two values appear close to TX power bar graph) When keyed down the TX with pump key the value settled at 7W out. (even although the ext. W-meter reads correct almost 40W)

character "6" is not sent in cw from keyboard

When in CW mode, I can send from the keyboard unitl I try to use the logbook. As soon as I enter a call into the log, the keyboard will no longer send CW. Thanks

Please learn to use gpiod and stop using wiring pi . People may want to use this on other boards then a raspi and wiringpi breaks on other systems

There may be a valid reason for the way Audio I/O is connected to the WM8731 pins in the SBITX V3, however I can't find a reason why those pins were chosen when I look at the WM8731 Datasheet (http://datasheet.elcodis.com/pdf2/88/68/886817/wm8731.pdf) and a sample implementation diagram (https://download.mikroe.com/documents/add-on-boards/click/audio-codec-proto-board/Audio%20Codec%20Board%20-%20PROTO_v102_Schematic.PDF), compare these to the SBITX v3 production schematic (https://github.com/afarhan/sbitx/blob/main/sbitx_v3_production.pdf) there is a clear difference.

This difference may explain the low mic gain issues in particular that have been reported in the forum.

The data sheet and the example diagram show the microphone circuit connected to pins 17 and 18, used also to provide bias for the microphone
The SBITX diagram shows the microphone circuit connection to pins 19 and 20 instead.

I haven't taken the board out to trace it through yet as I wanted to find documentation to help me identify where the audio routes are from a circuit perspective and not a software perspective as the software approach is dependant on the hardware approach to work properly together.

There may be a valid design reason for the approach taken, if that is the case please document it, if not then perhaps you need to document how this should be fixed for all those that have purchased this radio to address this problem because basically the radio is not really consistently usable in its current state for SSB modes of operation as delivered.

There may also be a need to review the physical audio output route too to ensure that is correctly wired as intended for SSB modes of operation. It appears that the digital modes side of the radio works ok, I have had many FT8 contacts though relied on external software to reliably operate on FT8, but that is not good for purchasers who wish to use phone modes of operation as well as digital with this radio.

All this has stemmed from the need to improve usability by providing the capability to use USB or Bluetooth headsets that many have raised.

Paul G0KAO

sudo modprobe snd-aloop enable=1,1,1 index=1,2,3
HDMI drivers are loaded at index 1, 2 and loopback at index 3.
Loopbacks are required at index 1, 2, 3.

cat /proc/asound/cards
0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard
audioinjector-pi-soundcard
1 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0
vc4-hdmi-0
2 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1
vc4-hdmi-1
3 [Loopback ]: Loopback - Loopback
Loopback 3

This problem can be fixed by adding the loopback driver in /etc/modules-load.d/modules.conf and loopback options in /etc/modprobe.d/alsa.conf

sudo nano /etc/modules-load.d/modules.conf
Add: snd-aloop
sudo nano /etc/modprobe.d/alsa.conf
Add: options snd-aloop index=1,2,3 enable=1,1,1

cat /proc/asound/cards
0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard
audioinjector-pi-soundcard
1 [Loopback ]: Loopback - Loopback
Loopback 1
2 [Loopback_1 ]: Loopback - Loopback
Loopback 2
3 [Loopback_2 ]: Loopback - Loopback
Loopback 3
4 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0
vc4-hdmi-0
5 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1
vc4-hdmi-1

Hopefully the image displays or is readable, when a user right-clicks the speaker icon on the task bar at the top right of the display and selects the Device Profiles option from the list, the attached image is displayed. in order to determine what each of the loopback interfaces does, it would be helpful to ensure they have an appropriate label even if it just matches the output from the aplay -l command to start with, but could do with more meaningful names rather than just Loopback for each interface.
Identified this issue in my quest to solve the headset related enhancement

Just added the snapshot of the PulseAudio Volume Controls:

just need to know what is what for this list? :-)

Dear Farhan,

I know you have a lot going on, and need to prioritise!

I just wanted to raise an issue with screen lag. Seems to happen when the sBitx has been left running for a while. The rig will tune but the display will not follow for a few seconds. I am using an 8GB Pi4.

For your info. when you have the time.

Thanks.

Daimon.

Please put a readme.nd with all the build depends for compiling and a basic howto . alot of people will have issues otherwise

Hello,

Wondering if there we any circuit board files like Kicad or Gerber that could be used to order a board from a circuit board company? I saw the main board pdf but it doesn't seem to layout the components any.

Can you clarify the purpose of the sleep(1) in the sound_thread_start function.

	pthread_create( &sound_thread, NULL, sound_thread_function, (void*)device);
	sleep(1);
	pthread_create( &loopback_thread, NULL, loopback_thread_function, (void*)device);

If this is attempting to get the sound_thread function running before loopback_thread runs it will not work as intended.
This is because there are a large number of threads potentially runnable as well as sound_thread.
Using sleep or any of the related functions is always a code 'smell'

Following your software update instructions:

$ cd sbitx

$ git pull
Updating 558ff8f..bd6d81c
error: Your local changes to the following files would be overwritten by merge:
data/user_settings.ini
Please commit your changes or stash them before you merge.
Aborting

Examining ~pi/data/user_settings.ini, we find my most recently used frequency, callsign, grid square, an so on.
Overwriting that file would cause all of my personalized settings to get lost.

The usual Linux convention is to use a hidden ("dot") file or directory in the user's home directory.
We find that it is already there, but it contains a callsign vu2lch, and other settings, from about a month ago.

$ ls -la ~pi/.sbitx
total 32
drwxr-xr-x 2 pi pi 4096 Jun 29 07:23 .
drwxr-xr-x 33 pi pi 4096 Aug 3 20:01 ..
-rw-r--r-- 1 pi pi 481 Jan 31 2022 bands.ini
-rw-r--r-- 1 pi pi 1346 Jan 31 2022 band_stack.ini
-rw-r--r-- 1 pi pi 1400 Jul 2 17:43 user_settings.ini
-rw-r--r-- 1 pi pi 12288 Feb 4 10:20 .user_settings.ini.swp

It looks like you intended to use $HOME/.sbitx/user_settings.ini but accidentally used $HOME/sbitx/data/user_settings.ini instead.

Temporary workaround:
Save the user settings file and copy it back again after the update.

$ cp data/user_settings.ini ~
$ git checkout -- data/user_settings.ini
$ git pull
Updating 558ff8f..bd6d81c
Fast-forward
data/user_settings.ini | 64 ++++++++++++++++++++++++-------------------------
modems.c | 36 ++++++++++++++++++----------
sbitx | Bin 403100 -> 403188 bytes
sbitx.c | 5 ++--
sbitx_gtk.c | 9 +++----
sbitx_wallpaper.png | Bin 122284 -> 124840 bytes
sdr.h | 1 +
7 files changed, 63 insertions(+), 52 deletions(-)

./build sbitx

I'm currently looking at the sBitx v2 from a software development perspective so not often transmitting. In the place I normally work I only have a receive active antenna so I don't want to transmit into that otherwise I might fry the active circuitry. A receive only setting would be useful. Maybe turning it on would set RF gain to 0, prevent the gain from being increased, lock out any transmit buttons or maybe doing something to prevent the transmitter code from being run. Then I can feel less worried about accidentally hitting a TX button!

line 107 in index.html is

<span class="slider-label">RF</span>

In other places this is referred to as IF gain. There is really no RF amplification. I think the RF slider label should be changed to "IF"

The builtin FT8 receive works great but I have not been able to transmit.

Power supply is 20A. Transmit power 10W.
Antenna tuner was adjusted for low SWR using antenna analyzer before connecting to sBitx.
The application was updated today.

I entered my callsign and grid square.

Clicking a station calling CQ and using the reply button, causes the application to terminate.
Same thing happens if I try using the FT8 CQ button.

This is what gdb has to say about the situation:

[Detaching after fork from child process 4266]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -11.6 dB
Decoded 14 messages
[Detaching after fork from child process 4269]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -11.5 dB
Decoded 14 messages
[Detaching after fork from child process 4271]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -10.8 dB
Decoded 15 messages
transmitting on 753
[Detaching after fork from child process 4273]
Packed data: e6 ed ee e7 38 a9 a1 1f aa 48

FSK tones: 3140652716447647142536160317463333253140652204551215173603670207123617723140652

Thread 1 "sbitx" received signal SIGSEGV, Segmentation fault.
0xb5e9cd80 in __GI__IO_fread (buf=0x90adc <ft8_tx_buff>, size=4, count=180000, fp=0x0) at iofread.c:37
37 iofread.c: No such file or directory.
(gdb)

(gdb) backtrace
#0 0xb5e9cd80 in __GI__IO_fread (buf=0x90adc <ft8_tx_buff>, size=4, count=180000, fp=0x0) at iofread.c:37
#1 0x000250a4 in ft8_tx (message=0xbeffeafc "WA4KBM WB2OSZ -10 ", freq=2140) at modems.c:261
#2 0x0001d718 in do_macro (f=0x56410 <main_controls+93016>, gfx=0x0, event=4, a=22, b=421) at sbitx_gtk.c:2224
#3 0x0001ef84 in on_mouse_press (widget=0x3898b0, event=0x394c80, data=0x0) at sbitx_gtk.c:2618
#4 0xb6936b8c in () at /usr/lib/arm-linux-gnueabihf/libgtk-3.so.0
(gdb)

I have read with interest your paper "sBITX – An open source SDR that you can hack" and couldn't resist trying.

I have installed sbitx on a fresh copy of 2020-12-02-raspios-buster-armhf-full on a rpi4.

The link "www.fftw3.org" should be www.fftw.org

When compiling sbitx the compiler complains about missing ncurses.h

this command helps:

sudo apt-get install ncurses-dev

Looking forward to the FDIM 2021 webinar

vy 73 de oz9ny, niels

Very poor CW sending from a key. I am not sure if the code is just missing dits and dahs or if it is because of a small delay in the sidetone that is causing me to miskey. By dialling down the CW timeout (QSK delay???) from 1000mS to 5mS, things improve slightly but my sending still sounds awful with missing characters. This is a major issue - CW is my only mode and I want the pleasure of sending with a key not a keyboard or macros, which actually appear to work properly. Plesae can we get this sorted or my radio becomes useless. Thanks.

		if (cw_tone.freq_hz != get_pitch())
			(&cw_tone, get_pitch(), 0);  <<< ???

Not sure what the intention of this comma expression is. The left hand and right hand operands have no effect.

Since, by default, the DE doesn't have the power/SWR measuring bridge and the code checks that, ignore the txcal command if the bridge is not detected. That way we won't mess up the gain settings.

If you can work on adding in js8call and a few other of the other digital odes also add in a logging software that has a sqlite db that you can pull from to upload to lotw and other places .

I have tested and it seems faster to me without any new problems.

gcc -Wall -Wextra -O2 -march=armv8-a -mfloat-abi=hard -mfpu=neon-fp-armv8 -g -o

Of course the -Wall -Wextra might be a bit much but I have updated my fork to clean up all the errors.

It's probably not advisable to run FT8 with RF gain set to 100. It would be useful to be able to define a default gain for each mode. For example, when I switch to FT8 change the gain to a user defined value, e.g. 30. That avoids switching from a mode where you can more safely use a higher gain to one that really needs a lower gain and forgetting to change the gain after the switch. Maybe have an extra option of either 'make this the maximum possible gain for this mode' or 'allow me to increase the gain after setting the default'.

Currently the sBITX is supporting all SW bands except 60m.
At least in Europe 60m is pretty interesting for FT8 as there is a general output power limit (essentially EIRP limit) that would most probably fit to the sBITX output power.
This means that all stations you hear, you will also be able to reach, as there won't be a 20Watts to 1.5kW mismatch as on the other bands ;-)
This enhancement will hopefully just be a SW change and the existing LP filters can be reused.

Remove code for the RTC from the sBitx code and instead let the Raspberry Pi OS manage it (it's trivial) and just let sBitx use the system time. For example, I have the RTC set up at the OS level and I also run chrony. Chrony can also manage time from a GPS dongle, if available, and gracefully manages multiple possible time sources (RTC, GPS, NTP), using whatever's available. It also automatically updates the RTC time when it gets time from a more accurate source.

Periodically, RX just stops. The Waterfall goes suddenly blank, nothing is received. Changing bands and back again does not help.
Quitting SBitx screen and restarting does not help.
Sometimes what look like birdies appear on the screen but no external signals.
A soft re-boot of the Raspberry Pi does not resolve it.
A hard reset (power cycle) seems to restore it.