sbitx's People
Forkers
tm9k1 orienhardt kc4vzt digitalhermes prajyotmandhare petermccracken gabs4 lscalpati jmlynesjr peterbmarks sbeckman w3jdr priestd09 rfjungle praveenbhandari rmaiap tisho88 fk8ih rhizomatica vu2lid radiodavid10 n6ln oirtstut n7ihq rafael2k g8kig alooriravali chimanraw rkayakr packman2008 dimaie microenh w5tsu jeremymturner uname-a mikekppp randrewthomas n1ai kholia galileosky vahalan sbitxdev maks-bax laluha drexjj ohmytime franklyrustech stnagy richneese warmspit sp9mrnsbitx's Issues
Mode vs BW settings
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:
- When mode is changed > the radio goes always to 3000Hz BW.
- BW label does not reflect the actual BW after mode switching and staying stuck on last BW value selected.
- 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.
Error in sbitx.c code - sBitx DE does not transmit
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");-
CW Pitch
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.
Blurred top right of the display.
Tuning knob switch as step change focus
I think using the tuning knob switch to change the step value is a good idea.
See discussion here on this and related topics.
.wav file, produced by sBitx REC button, is invalid.
The .wav file produced by the sBitx REC button can't be read by other applications.
One application reported that the data length was -1 which would not be possible.
Let's take a look at it in detail.
$ od -t x1 sbitx/audio/20220929-0138-12.wav | more
0000000 52 49 46 46 23 00 00 00 57 41 56 45 66 6d 74 20
----------- ----------- ----------- -----------
First 4 bytes "RIFF" - OK.
Next 4 bytes should be file length - 8.
(remaining length of file after these first 8 bytes.)
Instead we find 19 which is not puzzling. <--- *** ERROR ***
Next "WAVE" - OK
Next "fmt " - OK
0000020 10 00 00 00 01 00 01 00 e0 2e 00 00 c0 5d 00 00
----------- ----- ----- ----------- -----------
4 bytes for the format 16 - OK
2 bytes. 1=PCM. - OK
2 bytes. 1 channel (mono). - OK
4 bytes - 12000 samples per second - I was expecting 96000
4 bytes - 24000 block align * samples per second.
0000040 02 00 10 00 64 61 74 61 ff ff ff ff 81 fe c4 fe
----- ----- ----------- -----------.
2 bytes. 2 = block align - bits per sample / 8 * number of channels - OK
2 bytes. 16 bits per sample. - OK
4 bytes. "data" - OK
4 bytes. Should be number of bytes following.
Instead we find -1. <--- *** ERROR ***
0000060 44 fe 25 ff 9b 00 1b 01 f3 00 1c 01 35 01 6b 00
The problem is that the two length fields are not filled in.
When recording is finished, the application must seek to:
* offset 4 from beginning and fill in file length - 8.
* offset 40 from beginning and fill in file length - 44.
FT8 mis assigns callsign
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, ...
modem_ft8.c function ft8_message_tokenize line 713. Statement does not do anything.
code:
}
else
m3[0]; <<< This statement has no effect. Should it be
// m3[0] = 0;
// ???
return 0;
Enhancement: Labels for frequency memories.
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 set at 2000/01/01
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
Extra '%' in fprintf before 'BAND', gcc raises warning "unknown conversion type character ‘B’ in format"
Line 294 in 3b473b0
Logbook is empty
The logbook is not logging in contacts.
User settings written to disk very, very often
Line 1291 in 7abd77d
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?
RTC freezes
The RTC will (mostly) update the time at startup and be shown on the waterfall but then fails to update and freezes.
Change detection method for DE versus V2
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.
gtk3
where are you getting gtk3 for bullseye ? it is not in the pkgs and your binding the build to it
install.txt doesn't mention the need to install or configure fldigi
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
Enhancement: Ability to use a USB or Bluetooth Headset for audio modes i.e. SSB
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
RF Power indicator massively out
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.
sbitx build error with the new version 3
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 value mising
CW pitch on the display shows only Hz units but value is missing.
i2cbb.c function i2cbb_read_i2c_block_data possible missing curly brackets.
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();
}
Using the web UI, it is possible to select a blank entry in the Step Control
ntp not installed in standard image
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!
Are these allocations correct? (sbitx_sound.c)
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)?
Improper TX power reading
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
character "6" is not sent in cw from keyboard
CW keyboard does not work when log entry made
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
Wiringpi
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
Issue: are the audio connections to the WM8731 on the right pins
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
Raspberry Pi 4 HDMI audio modules conflict with loopbacks
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
Issue: inability to identify which loopback interface is which in the Device Profiles
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? :-)
Screen lag
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.
Build requirements
Please put a readme.nd with all the build depends for compiling and a basic howto . alot of people will have issues otherwise
Gerber or Kicad files
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.
sbitx_sound.c: sound_thread_start function: possible code 'smell'
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'
User Settings file interferes with software update
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
Suggestion: Receive Only setting
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!
user interface label
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"
FT8 transmit dies with segmentation fault.
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)
install.txt
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
Poor CW sending from key - nearly unusable
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.
File modem_cw.c function cw_tx_get_sample() line 359. Incomprehensible code.
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.
Suggestion: DE power calibration
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.
js8call
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 .
Suggestion: Compile with flags that optimise for the processor in the PI3/PI4.
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.
Suggestion: Define max RF gain per mode
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'.
Enhancement: 60m band support
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.
Move RTC support to the OS level
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.
RX suddenly stops
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.