Hi, my name is Lorenzo and I write from Italy.
This is my first message here, so nice to virtually meet you all!
I have a sBitx v3 board SN 0634, and while I'm 3D printing the case, I did some tests, after upgrading to v3.02.
It works perfectly in RX, in all modes I tested (SSB, CW and FT8) but when trying to transmit I got no output at all. The power meter reads 0W and SWR 1.0.
I tried it in FT8 and CW, and when switching to TX, the supply current rises from 400mA to 1.2A, but I have no power on the BNC connector. I tested with a tuner with built-in wattmeter, using my antenna and a 50W dummy load, no changes at all, regardless to the Drive setting.
The waveform display only shows a yellow straight line, without any modulation. As I'm an absolute beginner in the sBitx world, I don't know if I'm missing something. I checked the IRF510s and they seem fine. I also measured the voltage between Gate and Source while switching to TX, and it reads 4.33V, so I suppose the TX switching works fine. Any idea is greatly appreciated! Thanks!?
?73 de IU5RDU!

More fun things coming to the Toolbox soon! Here is a preview.











-JJ

On Sun, Feb 4, 2024 at 04:07 PM, Gordon Gibby wrote:

Those are 24 bit a to D ?converters. ?They have 80 to 90 DB dynamic ranges from the spec sheet. They are 30 or 40 or 50 DB more than we need!

?

Some people are selling systems with only eight bit eight bit ADC and that sounds pretty crappy but these are astonishingly good

I think my posting history shows I have a lot of Linux system programming and performance tuning in my background, not much DSP.

At my last job before retirement I did work with a bunch of professional DSP engineers, but they spoke a different language than I did.?

I spoke in terms of Linux, C and Python, they spoke in terms of MATLAB and Vivado.??

When I bought sbitx I thought I'd be spending most of my time using it to teach myself more about DSP.? That hasn't been the case so far.

I think we do have enough dynamic range, but we also have Rafael's statement that the DSP code he's using has problems due to the all-positive data they are being fed to them.

I think he also said he could scale the data if he knew what scaling factor to use, but didn't know how to come up with a good scaling factor.

Ideally this project would have access to one or more DSP engineers it could call on that could explain such things to C programmers.

I can think of one, but don't have his email address! :-)
?
--
Regards,
Dave, N1AI

开云体育

On Sun, Feb 4, 2024 at 03:48 PM, Gordon Gibby wrote:

Dave, to give an accurate answer will take a little bit of study, but remember these things work in an environment of positive supply voltages, without any negative supply voltage. So it’s likely that they only measure positive voltages. There are no negative voltages. And it’s also likely that the analog to digital converter is CD quality, with far more bits than our communications grade channel can support with a normal transceiver. So wasting 3DB worth of dynamic range may be negligible. I think I remember comments to that subject much earlier, when I get the chance I’ll go back and look at it, busy trying to make measurements to protect our new EOC from noise generators… Head is spinning with numbers

Thanks, Gordon, for the insights.? They are a good start!
?
--
Regards,
Dave, N1AI

On Sun, Feb 4, 2024 at 02:30 PM, Paul wrote:

Thanks Dave
That was going to be my approach anyway but was hoping, perhaps forlornly that it might have been done already :-)
I have been around IT for a long time(about 40 years ish) and know this is one of those areas that always gets overlooked. I was taught never to go near a computer keyboard until I understood what I wanted to achieve on paper first in a logical way at least :-)
I am not a programmer but know enough to be dangerous, and been around developers for a while at work before I finally gave up and retired :-)
I will dig in, might take me a while but once I have it drawn I will publish for others to correct :-)

Please do work at whatever pace you are comfortable.

This is supposed to be fun!?

This too is a 'retirement project' for me and I have to keep telling myself to make sure I'm having fun.

I think you are already "drinking from a fire hose" just by looking into how Linux audio works.

I don't want to overload you, but feel I should point things out then you can use them if/when you can/want to.

Having said this, one thought your post triggered is that if you use the 'perf' tools in Linux you should be able to get a nice call-graph of what calls what.

Because it's performance-based it will give you a good idea of what the important run-time flows are.

I remember being able to get nice graphs such as:



?has all the steps to making such a graph.? As usual, some googling may be needed to work through any issues encountered, etc.

This graph isn't the best example because the functions all have strange names, but the best I could do on short notice.

There's a lot more detail in such graphs than you need.

I remember learning a bit about the tools being used, then learning how to filter out the uninteresting stuff so the interesting stuff became more clear.

It is actually (IMO) fairly easy to hand-edit the 'dot' file once you understand its format, just save a back up each step of the way in case you prune too heavily.

If you want an absolute 'fire hose' page please look at??...

The Visualizations section with Flame Graphs and Heat Maps are very cool.

The side bar on the left top points you to even more of Brandon's work, which is amazing.

I think 'Linux events' will be even more useful for this project, since so much of what we do is sensitive to latency, more so than throughput.

With the events subsystem, you can get a time stamp every time a bunch of samples leave the codec, enter the sbitx app, pass through our dsp, etc.

So many things to look at, so little time.
?
--
Regards,
Dave, N1AI

Dave, to give an accurate answer will take a little bit of study, but remember these things work in an environment of positive supply voltages, without any negative supply voltage. So it’s likely that they only measure positive voltages. There are no negative voltages. And it’s also likely that the analog to digital converter is CD quality, with far more bits than our communications grade channel can support with a normal transceiver. So wasting 3DB worth of dynamic range may be negligible. I think I remember comments to that subject much earlier, when I get the chance I’ll go back and look at it, busy trying to make measurements to protect our new EOC from noise generators… Head is spinning with numbers

Gordon

On Sun, Feb 4, 2024 at 05:59 AM, Rafael Diniz wrote:

There are some old CFLAGS. I made a fork and fixed the Makefile to have sane intel and arm parameters:

Yes, now I remember not being able to come up with CFLAGS I was happy with.?

The problem was that csdr was using 'back door' methods to set the Linux pipe buffer sizes to get good performance, but modern Linuxes stopped supporting those 'back door' methods and the code would not compile.

I'm glad you came up with code you like, but I will point out that??says it's??ha7ilm/csdr:master.

This is actually more commits than were in the fork's parent!

So, if you run into issues, you may want to compare your code to the openwebrx fork to see if they have fixes you need.

Just to be sure - it makes no sense to add this DC component to tx
/ speaker paths, right?

[1]

Personally I would say it doesn't make sense.
I can't explain why it is happening.
Someone who is better with schematics and data sheets than I am should look into it, IMO.

That is my feeling too.

It would be nice if someone who is handy with analog electronics, schematics and data sheets would take on the mission of explaining why we end up with only positive numbers in the ADC output of the Wolfson Codec.

It would seem we are wasting over half the available dynamic range by doing this, no?
?
--
Regards,
Dave, N1AI

开云体育

On Sun, Feb 4, 2024 at 12:02 AM, Steve Barkes wrote:

The RPi would never work for Astronomy as there isn’t the software to support all I need to do.? It’s all Windows based.

?

The N100 won’t work for the SBITX as I don’t have any digital and analog ports? to control the radio.? No hardware interface to control the radio bits and bobs.

I'm trying to get people to think big picture and not think exact replacement with plug compatibility.

IMO there is a lot of overlap between what people use Pi for and what people use x86 stuff for, and the price points are converging rather than diverging.

This puts a lot of pressure on Pi to innovate.

Add to that Upton's desire to float Pi Trading, Inc onto the market, which adds more pressure to retain/expand markets.

IMO this will also put pressure on sbitx to keep moving forward.

If others want to keep running sbitx on Pi 4 in 32 bit mode on an obsolete version of linux, they should.

If others want to stay plug compatible, save money, and innovate all at the same time, they should sell their Pi 4 and get themselves a Pi Zero 2W and start hacking so it all works well in 512MB.

Maybe downgrade the OS to an even older version, because 6 year old code has to be more tried and true than 4 year old code.

Meanwhile I'll be working on Pi 5 with 8GB, fast NVMe storage, the currently supported Pi operating system, a modern IDE and build system, 64-bit mode etc.

I'll even try to be ready for Pi 6 when it shows up, which IMO will be sooner than most people think.

Personally, I'm more interested in moving forward and expanding the code base, rather than staying in the past and shrinking the code base, but to each their own.
?
--
Regards,
Dave, N1AI

Thanks Dave
That was going to be my approach anyway but was hoping, perhaps forlornly that it might have been done already :-)
I have been around IT for a long time(about 40 years ish) and know this is one of those areas that always gets overlooked. I was taught never to go near a computer keyboard until I understood what I wanted to achieve on paper first in a logical way at least :-)
I am not a programmer but know enough to be dangerous, and been around developers for a while at work before I finally gave up and retired :-)
I will dig in, might take me a while but once I have it drawn I will publish for others to correct :-)

Regards
Paul G0KAO

Barry

Any luck resolving the issue?


-JJ

On Sun, Feb 4, 2024 at 01:57 PM, Paul wrote:

Just need the software equivalent of this diagram to understand the code modules and how they fit together, and what parameters are passed between each code module

May I suggest you use the FAFO (f--- around, find out) method first, then try to work out the architecture?

Sorry, but if you are waiting for such a diagram, you will be waiting for a very long time, IMO.

I don't know of any good tool to automatically draw such a block diagram.

If someone knows of such a tool. please speak up.

I don't know of any manually-drawn diagrams for this code base.

The best method I know of is the UTSL method (Use the Source, Luke).

You gotta read the code.
?
--
Regards,
Dave, N1AI

On Sun, Feb 4, 2024 at 11:59 AM, Dave, N1AI wrote:

I have done manual setups for using RTP streams using Pulse in Debian 11 with the "quisk" app driving the Hermes-Lite 2 SDR.

It more or less happens automatically if you use ssh with x-windows tunneling enabled, but you may need to set some environment variables to get things to work the way you want.

To try to add more detail, if you do 'man ssh' on a linux box you should see the '-X' option described as:


?
I guess it's proper name is "X11 forwarding" but most of us call it "tunneling".

On my Linux laptop I enable this by default by having the following in .bashrc:



When I use ssh from my laptop to the sbitx pi then start the 'vlc' program, its video is sent in the ssh tunnel using X forwarding to my laptop.

If I then use vlc's 'Media -> Open File' menu to open an audio file and hit the || button to play, I hear the audio.

The tunnel contains both xlib primatives for graphics as well as RTP/RTSP streams for audio.

This works because vlc is sending audio to the default PulseAudio device on the sbitx which is sending the audio via RTP that is then tunneled by ssh session to the Linux laptop which then sends it to the local PulseAudio to play on the laptop's default device.

If you run the PulseAudio 'pavucontrol' app on the laptop you can see that it is getting audio from VLC which is NOT running on the laptop!



If I start the sbitx application I do see its video, but do not hear any audio, it is playing to the sbitx speaker still.?

This is because the sbitx application hard codes use of the ALSA 'audioinjectorpi' device which writes the audio samples to the sbitx speaker.??

If you have a good 'ssh' client for Windows I believe all the same things will still happen when you use the equivalent of the '-X' flag to start it.

My favorite is MobaXterm ( ,? ).??

My head exploded when I first encountered it in the late 2010s.? It has an entire X server, plus ssh client, plus bash, plus all the rest of the Cygwin linux command set for DOS, plus lots of other stuff, all in a single Windows application?? I had worked with X on early RISC processors of the 1980s and 1990s, as well as early Linux x86 boxes from '386 onward.? All that stuff in a single Windows program?? I just could not believe it!!!

Having said that, these days I don't use Windows much so I have never tried it for this exact purpose, but I am pretty confident that it will work.

--
Regards,
Dave, N1AI

开云体育

I would listen to my broadcast . This way, the setting will be personalized.
--
Gyula HA3HZ

Hi David,

Thanks for the response. It is available with Adafruit. I have clone version. But it works.
I have put a 2k pot to ground on the O/P and wiper is presently connected to my PC to see the O/P.

The compression ration of this chip is 1:500 1:2000 and 1:4000. I cannot understand which is the best.

Regards
Ashok

Using google, the manufacturer's description is:
You can set the AGC and the gain to 3 different settings.
Details in the description.
--
Gyula HA3HZ