开云体育

  1. BITX20
  2. Messages
Expanded Topics Messages Polls
Date
Re: Radio S32LE samples don't go negative?

 

See the display difference on your scope in AC and DC mode.

Raj

On 03/02/2024 2:51 PM, Rafael Diniz wrote:
There is something wrong. I'm looking at the samples I get from the radio rx path - I don't see negative samples, just positive ones, but the sample format is signed 32 bits. When reading from loopback, for example, I get the negative and positive samples, as expected. This explains weird behaviors I was experiencing. Anyone can confirm this issue?

Cheers,
Rafael
Re: SBITX v3 - Ability to use a Headset for phone modes

Paul
 

Thanks Ashar
I am guessing you mean sbitx_sound.c as I can’t find the one you said :-)
Re: Software Dreaming

 

Dave-
Thanks for the info - that saved me some research time!? I will look into that design and see what it looks like.Tnx agn , great group here!

Rich,
WE8T
Re: sBIT USB boot

 

The N100 vs RPi 5 debate seems to ignore those 40 pins on the RPi that the N100 solutions lack.

Are we trying to solve a software problem or a hardware problem?

I think you'd be hard-pressed to just "drop in" an N100 system in a device like the uBitx, there would be a significant effort to interface the N100 system to a uBitx board I imagine.

N100 systems are great values and solve a number of problems, but they are not suitable in some applications the RPi excels at, namely embedded applications.

If your application doesn't require the 40 pin GPIO header, why are you using an RPi?

NOTE: if $100-150 N100 systems were available at the time, Mr Upton would never have developed the RPi - his goal was a $100ish desktop that required a TV for output that could be used in education for third-world students using phone chargers, cheap keyboards/mice, etc.

Ken, N2VIP

On Jan 23, 2024, at 15:00, Dave, N1AI <n1ai@...> wrote:

It also fits into some stuff I wrote earlier about how I feel Pi will be under more pressure from small form-factor (SFF) PCs using x86 processors, and that the sBITX community will have to be ready for things to change more rapidly than in the past
Re: Radio S32LE samples don't go negative?

 

We zero out all bins except the central bins as a part of convolution filtering.


On Sat, Feb 3, 2024, 6:35 PM Rafael Diniz <rafael@...> wrote:
And for transmit / speaker, should such offset be used or 0 centered
sample signal can be used?

- Rafael

On 2/3/24 12:56, Ashhar Farhan wrote:
> This offset will show as dc spike (and it does) on bin zero. We don't
> display or use that bin at all.
> - f
>
> On Sat, Feb 3, 2024, 5:01 PM Rafael Diniz <rafael@...> wrote:
>
>? ? ?There seem to be an offset according to capture level and signal
>? ? ?intensity, but I can not (at least not easily) determine the offset.
>
>? ? ?- Rafael
>
>? ? ?On 2/3/24 09:37, Gordon Gibby wrote:
>? ? ?> Is there a constant offset?? ?Try listening to a steady carrier
>? ? ?which should result in a sine wave in the audio.
>? ? ?>> On Feb 3, 2024, at 04:21, Rafael Diniz <rafael@...>
>? ? ?wrote:
>? ? ?>>
>? ? ?>> ?There is something wrong. I'm looking at the samples I get
>? ? ?from the radio rx path - I don't see negative samples, just
>? ? ?positive ones, but the sample format is signed 32 bits. When
>? ? ?reading from loopback, for example, I get the negative and
>? ? ?positive samples, as expected. This explains weird behaviors I was
>? ? ?experiencing. Anyone can confirm this issue?
>? ? ?>>
>? ? ?>> Cheers,
>? ? ?>> Rafael
>? ? ?>>
>? ? ?>>
>? ? ?>>
>? ? ?>>
>? ? ?>>
>? ? ?>>
>? ? ?>>
>? ? ?>
>? ? ?>
>? ? ?>
>? ? ?>
>
>
>
>
>
>





Re: Radio S32LE samples don't go negative?

 

And for transmit / speaker, should such offset be used or 0 centered sample signal can be used?

- Rafael

On 2/3/24 12:56, Ashhar Farhan wrote:
This offset will show as dc spike (and it does) on bin zero. We don't display or use that bin at all.
- f

On Sat, Feb 3, 2024, 5:01 PM Rafael Diniz <rafael@...> wrote:

There seem to be an offset according to capture level and signal
intensity, but I can not (at least not easily) determine the offset.

- Rafael

On 2/3/24 09:37, Gordon Gibby wrote:
> Is there a constant offset?? ?Try listening to a steady carrier
which should result in a sine wave in the audio.
>> On Feb 3, 2024, at 04:21, Rafael Diniz <rafael@...>
wrote:
>>
>> ?There is something wrong. I'm looking at the samples I get
from the radio rx path - I don't see negative samples, just
positive ones, but the sample format is signed 32 bits. When
reading from loopback, for example, I get the negative and
positive samples, as expected. This explains weird behaviors I was
experiencing. Anyone can confirm this issue?
>>
>> Cheers,
>> Rafael
>>
>>
>>
>>
>>
>>
>>
>
>
>
>





OpenPGP_signature.asc
OpenPGP_signature.asc

Re: Radio S32LE samples don't go negative?

 

This offset will show as dc spike (and it does) on bin zero. We don't display or use that bin at all.
- f

On Sat, Feb 3, 2024, 5:01 PM Rafael Diniz <rafael@...> wrote:
There seem to be an offset according to capture level and signal
intensity, but I can not (at least not easily) determine the offset.

- Rafael

On 2/3/24 09:37, Gordon Gibby wrote:
> Is there a constant offset?? ?Try listening to a steady carrier which should result in a sine wave in the audio.
>> On Feb 3, 2024, at 04:21, Rafael Diniz <rafael@...> wrote:
>>
>> ?There is something wrong. I'm looking at the samples I get from the radio rx path - I don't see negative samples, just positive ones, but the sample format is signed 32 bits. When reading from loopback, for example, I get the negative and positive samples, as expected. This explains weird behaviors I was experiencing. Anyone can confirm this issue?
>>
>> Cheers,
>> Rafael
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
Re: Distorted audio on DE

 

The resistor that supplies power to LM380 is probably charred. Replace or short it.


On Sat, Feb 3, 2024, 2:29 PM HA3HZ <gyula@...> wrote:
Robert,

The audio frequency final amplifier uses LM380N, which can operate from 10V to 22V.
If you use it from an external battery, it is possible that the voltage of the battery drops below 10V.
In this case, your radio will be muted, it will only work with headphones.
I haven't tried it, I just think there might be some distortion near 10V before it turns off completely.
?
--
Gyula HA3HZ

Re: Radio S32LE samples don't go negative?

 

There seem to be an offset according to capture level and signal intensity, but I can not (at least not easily) determine the offset.

- Rafael

On 2/3/24 09:37, Gordon Gibby wrote:
Is there a constant offset? Try listening to a steady carrier which should result in a sine wave in the audio.
On Feb 3, 2024, at 04:21, Rafael Diniz <rafael@...> wrote:

?There is something wrong. I'm looking at the samples I get from the radio rx path - I don't see negative samples, just positive ones, but the sample format is signed 32 bits. When reading from loopback, for example, I get the negative and positive samples, as expected. This explains weird behaviors I was experiencing. Anyone can confirm this issue?

Cheers,
Rafael







OpenPGP_signature.asc
OpenPGP_signature.asc

Re: SBITX v3 - Ability to use a Headset for phone modes

 

Paul,
See the mixer functions of sound_sbitx.c, they should help.

On Sat, Feb 3, 2024, 4:04 PM Paul <g0kaohx@...> wrote:
Essentially that is what the loopback interfaces are. So what I have done is identified the existing loopback interfaces and how they are used, I have then created a new pair ready to route the sbitx audio to a different device.
To illustrate:
Loopback 1 is used to send receive audio from the sbitx app at a fixed volume level to the digital software e.g. wsjt-x
Loopback 2 is used to capture output(mic) audio from the digital software e.g. wsjt-x and feed that back to the sbitx app for transmission

I have created a new pair of Loopback interfaces (3 & 4) to replicate this functionality with a USB connected audio device/headset but I need the source audio to have adjustable volume(gain) controls for SSB purposes.
That is the next puzzle to solve which will involve a bit of coding in the sbitx application. I will investigate this but need to better understand the coding architecture so that I can have a go at making the required updates.
At least the structural foundation is there now from a hardware perspective.

Regards
Paul G0KAO
Re: SBITX v3 - Ability to use a Headset for phone modes

Paul
 

Essentially that is what the loopback interfaces are. So what I have done is identified the existing loopback interfaces and how they are used, I have then created a new pair ready to route the sbitx audio to a different device.
To illustrate:
Loopback 1 is used to send receive audio from the sbitx app at a fixed volume level to the digital software e.g. wsjt-x
Loopback 2 is used to capture output(mic) audio from the digital software e.g. wsjt-x and feed that back to the sbitx app for transmission

I have created a new pair of Loopback interfaces (3 & 4) to replicate this functionality with a USB connected audio device/headset but I need the source audio to have adjustable volume(gain) controls for SSB purposes.
That is the next puzzle to solve which will involve a bit of coding in the sbitx application. I will investigate this but need to better understand the coding architecture so that I can have a go at making the required updates.
At least the structural foundation is there now from a hardware perspective.

Regards
Paul G0KAO
Re: Radio S32LE samples don't go negative?

 

Is there a constant offset? Try listening to a steady carrier which should result in a sine wave in the audio.

On Feb 3, 2024, at 04:21, Rafael Diniz <rafael@...> wrote:

?There is something wrong. I'm looking at the samples I get from the radio rx path - I don't see negative samples, just positive ones, but the sample format is signed 32 bits. When reading from loopback, for example, I get the negative and positive samples, as expected. This explains weird behaviors I was experiencing. Anyone can confirm this issue?

Cheers,
Rafael






OpenPGP_signature.asc
OpenPGP_signature.asc

Radio S32LE samples don't go negative?

 

There is something wrong. I'm looking at the samples I get from the radio rx path - I don't see negative samples, just positive ones, but the sample format is signed 32 bits. When reading from loopback, for example, I get the negative and positive samples, as expected. This explains weird behaviors I was experiencing. Anyone can confirm this issue?

Cheers,
Rafael

OpenPGP_signature.asc
OpenPGP_signature.asc

Re: Distorted audio on DE

 

Robert,

The audio frequency final amplifier uses LM380N, which can operate from 10V to 22V.
If you use it from an external battery, it is possible that the voltage of the battery drops below 10V.
In this case, your radio will be muted, it will only work with headphones.
I haven't tried it, I just think there might be some distortion near 10V before it turns off completely.
?
--
Gyula HA3HZ
Re: Best way to use #sbitx with N3FJP, WINLINK, other Windows ham radio apps? #sBitx

 

I searched for LOG programs because the sBitx 7" LCD display with 800x480 pixels is too small for all the published programs.
The useful surface of the screen determines what can fit and I found quite a few usable LOG programs for this size.
I'm not saying there isn't one, but I haven't found it.
Yes, I know the Move option called by pressing Alt+space+M at the same time.
The OK option is usually in the lower parts of the window if you change something and want to save it.
I wrote earlier, I tested several programs on this interface.
It's good for Tlf competition, I didn't like PyQSO for some reason, Xlog is stored in text, not in a database.
What I then used for a longer time was YFKlog. Its author is unable to develop it due to his current work, but it is usable with the fixes he sent me.

Jeremy,
when I first wanted to try Wine in connection with a NanoVNA program, it only worked with the pre-installed Wine, which is in the TwisterOSv2-1-2 image.
I think the Mac has a similar problem, that during development, some files collide, which prevents it from working correctly.
I did not deal with this further, as I had reached my goal and the specific Windows program was working.
Coming back to the LOG files, I'm looking at the links above, but haven't had time to try these improvements yet.
--
Gyula HA3HZ
Re: SBITX v3 - Ability to use a Headset for phone modes

Paul
 

Hi Gordon
While that may be possible I think it might need a bit more work, however once the routing of audio is possible to a USB headset or other audio device, then yes if for example you had another computer running JTDX, then yes at least from an audio perspective only, you could connect it to the sbitx audio.
What I have achieved so far with the steps outlined is the consistent ability to identify a USB connected audio device in this case that can be hotplugged into the sbitx without affecting the current audio delivery to the core functions of the radio.
The challenge now is to sort out the routing of the audio from the sbitx application to the USB audio, if you try the command line arecord command using the existing loopback feed it does work, but the audio level is fixed, this might be good enough for digital modes output to another computer but its not really enough for SSB work which is the bit I want to address.
I quote JTDX because it is my preferred FT8 application but the same applies for other digiital audio applications too.
It does have the potential to open up other possible audio use cases I think once this is sorted.

Regards
Paul G0KAO
Re: sBIT USB boot

Paul
 

Just to be aware, when there is no USB boot drive connected, a splash screen is displayed until the pi boots from the SD card inviting you to press a key, don’t, be patient and wait for the pi to start booting from the SD card as it will if left. I nearly fell for it but remembered patience is key :-)
Regards
Paul G0KAO
Re: FLdigi issues on SBITX #sBitx #fldigi

 

Hi, is anyone using full FlDigi?? Still curious about questions and the original post.
Re: sBIT USB boot

 

Regarding booting from an external USB device ...

... you can change the boot order in the "raspi-config" terminal program, and just leave the micro-SDcard in place.

Just be aware that the Pi will take around 30 seconds to boot from the internal micro-SDcard when it doesn't find an external USB Drive to boot from, if choosing the "USB boot first" option.

You can use this setup to either play with a new OS, or just to have a backup OS ready to go if one fails.
--

Pete VK3PYE
Re: SBITX v3 - Ability to use a Headset for phone modes

 

Paul,? do I understand this properly:? ? with your solution, a straight-through USB cable from your headset output to a USB connector on a DIFFERENT computer, would appear to be the digital output of a sound card?? ?(Not the analog output that would go to a normal physical speaker)

Do I understand that correctly?
Thanks,
Gordon KX4Z


On Fri, Feb 2, 2024 at 6:10?PM Paul <g0kaohx@...> wrote:
A little progress made to solve a bit of a thorny issue regarding what happens when the sbitx is rebooted when a usb device is connected like a headset. Sorry bit of a long post, but it needs to be.
Not much point in connecting things up if a reboot changes the order of devices, this has involved a fair amount of learning and research but hopefully it has been worth it.
  • I know if I run the speaker-test -D default -c 1 -t wav command the sound comes out of the sbitx speaker
  • If I run the?speaker-test -D plughw:CARD=II,DEV=0 -c 1 -t wav command, the sound comes out of my USB headset
and then if I run the arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0" and then start the sbitx app, I get sound from the radio fed to both the speaker and my USB headset. The headset volume is a little on the low side but it is usable and is progress. Adding the -f cd option to the arecord command actually improves the audio quality fed to the headset by reducing some of the noise level on the audio from the radio.

I have now updated the /etc/rc.local file to create/amend the number of Loopback devices available:
modprobe snd-aloop enable=1,1,1,1 index=1,2,3,4

(If you are not interested in connecting other headset devices e.g. USB or Bluetooth, I would amend this line to read modprobe snd-aloop enable=1,1 index=1,2 to remove the unwanted Loopback_2 interface to keep things simple and tidy.)

Using this update creates 4 loopback interfaces so that when cat /proc/asound/cards is run you get a list of the available sound cards:

pi@sbitx:~ $ 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 [Loopback_3? ? ?]: Loopback - Loopback
? ? ? ? ? ? ? ? ? ? ? Loopback 4

We know that audioinjectorpi (card 0) is used for the sbitx audio I/O
We know that Loopback (card 1) is used for the output to digital software such as JTDX, FLDIGI etc.
We know that Loopback_1 (card 2) is used as the capture interface from the digital software such as JTDX, FLDIGI etc.
As delivered Loopback_2 (card 3) is not used for anything (that I can find anyway)
So to mirror the digital audio I/O I created an additional Loopback interface using the update to /etc/rc.local

Now for the device order problem: when I connected the USB headset after powering on the radio it would appear at the end of the list using cat /proc/asound/cards:
pi@sbitx:~ $ 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 [Loopback_3? ? ?]: Loopback - Loopback
? ? ? ? ? ? ? ? ? ? ? Loopback 4
?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II
? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed
pi@sbitx:~ $?

However if I rebooted the radio with the USB device still connected then the listing would look like?

pi@sbitx:~ $ pactl list cards short

54??????????????alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00????????????alsa

55??????????????alsa_card.platform-soc_sound??????????????????alsa

56??????????????alsa_card.platform-snd_aloop.2???????????????alsa

57??????????????alsa_card.platform-snd_aloop.1???????????????alsa

pi@sbitx:~ $

NOTE the different command used, still achieves the same thing and this was being used before I got to my solution. The issue here is that the USB device is now top of the ordered list and prevents sbitx from accessing the audioinjectorpi card because the USB device is now hw:0,0 instead of the audioinjector pi device. Note also that a Loopback interface has also disappeared!
if I unplug the USB device and reboot the correct order is resumed :

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.platform-soc_sound????????????????? alsa

55????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

56????????????? alsa_card.platform-snd_aloop.0?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

pi@sbitx:~ $

Normal service is resumed now, If I connect the USB headset again it gets added to the list at the end as it should:

connect headset:

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.platform-soc_sound????????????????? alsa

55????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

56????????????? alsa_card.platform-snd_aloop.0?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

106?????????? alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00??????????? alsa

pi@sbitx:~ $


Reboot again with the headset connected just to prove the point:

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00??????????? alsa

55????????????? alsa_card.platform-soc_sound????????????????? alsa

56????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

pi@sbitx:~ $


After headscratching, extensive use of Google and testing and retesting here is the solution:
In order to consistently achieve a correct order of devices a couple of commands were used to determine device names, note that I am totally focussed on using ALSA here to minimise complexity.
What we need to achieve is this order whenever the device is rebooted:
pi@sbitx:~ $ cat /proc/asound/modules
?0 (efault)
?1 snd_aloop
?2 snd_aloop
?3 snd_aloop
?4 snd_aloop
?5 snd_usb_audio
pi@sbitx:~ $?

or

pi@sbitx:~ $ 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 [Loopback_3? ? ?]: Loopback - Loopback
? ? ? ? ? ? ? ? ? ? ? Loopback 4
?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II
? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed
pi@sbitx:~ $

The solution is straightforward when you know how and what it is but it took a bit of finding along with trial and error :-)
Create this file (it doesn't exist on the delivered sbitx) using the command:
sudo nano /etc/modprobe.d/alsa-base.conf?

Add these lines to the file:
options (efault) index=-2? ? ? ? ? ? ? ? ? ? ? ? ? #am sure this should say default in the brackets but that is how the hw:0,0 device we want was listed in the cat /proc/asound/modules command
options snd_usb_audio index=5
?
Save the file and reboot with the USB device still connected. Note it is the output from the command cat /proc/asound/modules command that is important for this to identify the correct device names to use in the file. The higher the index value, the lower down the priority list they appear. to be really sure it might be worth adding the all the interface modules with an assigned index value to properly maintain the list order.

Do the check commands to ensure the USB device is at the bottom of the list (index=5) following reboots:
pi@sbitx:~ $ 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 [Loopback_3? ? ?]: Loopback - Loopback
? ? ? ? ? ? ? ? ? ? ? Loopback 4
?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II
? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed

pi@sbitx:~ $ cat /proc/asound/modules
?0 (efault)
?1 snd_aloop
?2 snd_aloop
?3 snd_aloop
?4 snd_aloop
?5 snd_usb_audio
pi@sbitx:~ $?
?
Now that bit is sorted we can start to try and reliably route audio to a USB headset based on the knowledge that the device whether plugged in or not won't affect the core audio routing of the sbitx radio.?
Just got to work that bit out now using the Loopback_2 for playback to the USB device and Loopback_3 for capture from the USB device microphone, that way we don't impact the digital functionality of the radio.
Might need some coding help with that bit, logically I know it can be done having proved some of the routing via the command line earlier, but now need the output from the codec that feeds the speaker and Loopback(card 1) to also feed Loopback_3(card 3) for play with a volume control (maybe using the Master Volume)? capability to drive the headset with more audio.?
Another option would be to take the output/input directly to/from the USB device but maybe that's a bit trickier

I believe an alternative headset solution is now a bit nearer

Regards
Paul G0KAO
8821 - 8840 of 116134