Topics

Modular uBitx - "Ex: Harmonics"

Tom, wb6b
 

I think a modular transceiver, SDR or analog, is a great idea, and I'm seeing some links to transceivers that look very interesting. But, I think trying to convert the uBITX transceiver to something completely different may not be necessary. The uBITX hits a sweet spot, because it is not overly complicated and has the cost benefit of being just one board. For us hackers it provides a low cost radio component we can slice, dice, hacksaw, mod and accessorize anyway we wish.

The folks with the Ham Radio hacker sprit, that are slicing and dicing their radios, are helping to lead the way to another cost effective uBITX for the next round of experimentation.  And, of course, use as is.

As technology advances, the point where it makes more sense to have a single replaceable component travels towards a singe replaceable component.

I'm sure at one time a company having 64GB of storage in their computing environment justified having a whole department of managers and specialist to manage the memory, make budget predictions, determine upgrade paths.  And to, of course, become the department that had the power to be the authority to control who had access to this valuable asset.

Now 64GB of storage can come in a package shaped like Garfield the Cat. Nobody is worried about modularizing it, and nobody feels much pain if it is just tossed (recycled) if it fails. 

At some point, and the uBITX is getting close, just thinking of the whole transceiver as a replaceable component makes sense. But, that doesn't stop all of us that do like to hack on it, from doing so and making something better. Or treating the uBITX as just a component in a bigger system we are building.

Tom, wb6b

Glenn
 

Take a look at Hans new SSB/CW etc rig. And future 10 band capability......

https://www.youtube.com/watch?v=hL6CWaY438Y&feature=youtu.be

Jack, W8TEE
 

That's exactly where we hope to take it. I've had 4 SDR radios and enjoyed every one of them. However, I don't like being tethered to a PC or laptop. I'm hoping that, collectively, we can create a standalone SDR radio that doesn't cost an arm and a leg.

Jack, W8TEE


On Wednesday, August 15, 2018, 6:06:33 PM EDT, Dr. Flywheel <Dr.Flywheel@...> wrote:


By utilizing a Teensy 3.6 board you are opening the way for DSP-based generation and reconstruction of SSB and other signals. For example a pair of 45 deg. symmetrical Hilbert transforms can take care of precise phasing to effectively suppress the carrier and unwanted sideband. Such Hilbert filter can simultaneously replace the second IF crystal filter, if the conversion is brought down to audio frequencies. Being a programmable filter, the Hilbert transform can also provide variable bandwidth for the desired mode of operation. Further audio processing, like the audio band equalizer that you apparently implemented is just as icing on the cake. With appropriate CODEC, the Teensy 3.6 with its DMA capabilities, can easily support 192 kHz sampling rate, which means that in principle you could show FFT an waterfall diagrams in real time for a much wider bandwidth. This becomes essentially a hybrid SDR architecture at a very low cost.

--Ron   N7FTZ   

On Wed, Aug 15, 2018 at 10:19 AM Jack Purdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Carl:

Some very good ideas.

I'm showing the Rev 2 JackAl board here, partly to show what we done, but also to show the mistakes we made along the way. (We're doing
Inline image
the Rev 4 board now.) First, we've taken the buck converter off simply because it was too fragile when adjusting...far to easy to rip the adjusting screw right off the board. Second, the 7W audio amplifier (big IC on lower left) is stupid for the nano acres it takes plus its cost. Most users have powered speakers or can easily add them. We don't have a direct I2C connection, but we do have an SPI interface for the touch screen display. (Our display handles the video processing.) The rest are connections that work through the exiting µBITX headers, which would not be the same for a new design. Still, the above is less than 100mm x 100mm and parts are being taken off. Obviously, we have the Si5351 chip onboard, but that probably should be on the main board. The SMD parts will be part of the PCB when sold.

To me, perhaps the most important thing we've done is bring out a bunch of pins, both digital and analog, for others to use. I hope the selected processor for such a project has a bunch available.

Jack, W8TEE



On Wednesday, August 15, 2018, 12:27:03 PM EDT, RCBoatGuy via Groups.Io <ijnfan-HamRadio=yahoo.com@groups.io> wrote:


Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC

W2CTX
 

Experimentally already exists in the form of code running in a STM32F746NG

driving https://www.hobbypcb.com/rs-hfiq.



On August 15, 2018 at 10:41 PM "Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

That's exactly where we hope to take it. I've had 4 SDR radios and enjoyed every one of them. However, I don't like being tethered to a PC or laptop. I'm hoping that, collectively, we can create a standalone SDR radio that doesn't cost an arm and a leg.

Jack, W8TEE
 


On Wednesday, August 15, 2018, 6:06:33 PM EDT, Dr. Flywheel <Dr.Flywheel@...> wrote:


By utilizing a Teensy 3.6 board you are opening the way for DSP-based generation and reconstruction of SSB and other signals. For example a pair of 45 deg. symmetrical Hilbert transforms can take care of precise phasing to effectively suppress the carrier and unwanted sideband. Such Hilbert filter can simultaneously replace the second IF crystal filter, if the conversion is brought down to audio frequencies. Being a programmable filter, the Hilbert transform can also provide variable bandwidth for the desired mode of operation. Further audio processing, like the audio band equalizer that you apparently implemented is just as icing on the cake. With appropriate CODEC, the Teensy 3.6 with its DMA capabilities, can easily support 192 kHz sampling rate, which means that in principle you could show FFT an waterfall diagrams in real time for a much wider bandwidth. This becomes essentially a hybrid SDR architecture at a very low cost.

--Ron   N7FTZ   

On Wed, Aug 15, 2018 at 10:19 AM Jack Purdum via Groups.Io <jjpurdum= yahoo.com@groups.io> wrote:
Carl:

Some very good ideas.
 

I'm showing the Rev 2 JackAl board here, partly to show what we done, but also to show the mistakes we made along the way. (We're doing
Inline image
the Rev 4 board now.) First, we've taken the buck converter off simply because it was too fragile when adjusting...far to easy to rip the adjusting screw right off the board. Second, the 7W audio amplifier (big IC on lower left) is stupid for the nano acres it takes plus its cost. Most users have powered speakers or can easily add them. We don't have a direct I2C connection, but we do have an SPI interface for the touch screen display. (Our display handles the video processing.) The rest are connections that work through the exiting µBITX headers, which would not be the same for a new design. Still, the above is less than 100mm x 100mm and parts are being taken off. Obviously, we have the Si5351 chip onboard, but that probably should be on the main board. The SMD parts will be part of the PCB when sold.

To me, perhaps the most important thing we've done is bring out a bunch of pins , both digital and analog, for others to use. I hope the selected processor for such a project has a bunch available.

Jack, W8TEE



On Wednesday, August 15, 2018, 12:27:03 PM EDT, RCBoatGuy via Groups.Io <ijnfan-HamRadio= yahoo.com@groups.io> wrote:


Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC


 


 

Jack, W8TEE
 

Still not a standalone system and requires a PC to process the signals. The cost's not bad if it were self-contained.

Jack, W8TEE


On Wednesday, August 15, 2018, 11:04:35 PM EDT, W2CTX <w2ctx@...> wrote:


Experimentally already exists in the form of code running in a STM32F746NG

driving https://www.hobbypcb.com/rs-hfiq.



On August 15, 2018 at 10:41 PM "Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

That's exactly where we hope to take it. I've had 4 SDR radios and enjoyed every one of them. However, I don't like being tethered to a PC or laptop. I'm hoping that, collectively, we can create a standalone SDR radio that doesn't cost an arm and a leg.

Jack, W8TEE
 


On Wednesday, August 15, 2018, 6:06:33 PM EDT, Dr. Flywheel <Dr.Flywheel@...> wrote:


By utilizing a Teensy 3.6 board you are opening the way for DSP-based generation and reconstruction of SSB and other signals. For example a pair of 45 deg. symmetrical Hilbert transforms can take care of precise phasing to effectively suppress the carrier and unwanted sideband. Such Hilbert filter can simultaneously replace the second IF crystal filter, if the conversion is brought down to audio frequencies. Being a programmable filter, the Hilbert transform can also provide variable bandwidth for the desired mode of operation. Further audio processing, like the audio band equalizer that you apparently implemented is just as icing on the cake. With appropriate CODEC, the Teensy 3.6 with its DMA capabilities, can easily support 192 kHz sampling rate, which means that in principle you could show FFT an waterfall diagrams in real time for a much wider bandwidth. This becomes essentially a hybrid SDR architecture at a very low cost.

--Ron   N7FTZ   

On Wed, Aug 15, 2018 at 10:19 AM Jack Purdum via Groups.Io <jjpurdum= yahoo.com@groups.io> wrote:
Carl:

Some very good ideas.
 

I'm showing the Rev 2 JackAl board here, partly to show what we done, but also to show the mistakes we made along the way. (We're doing
Inline image
the Rev 4 board now.) First, we've taken the buck converter off simply because it was too fragile when adjusting...far to easy to rip the adjusting screw right off the board. Second, the 7W audio amplifier (big IC on lower left) is stupid for the nano acres it takes plus its cost. Most users have powered speakers or can easily add them. We don't have a direct I2C connection, but we do have an SPI interface for the touch screen display. (Our display handles the video processing.) The rest are connections that work through the exiting µBITX headers, which would not be the same for a new design. Still, the above is less than 100mm x 100mm and parts are being taken off. Obviously, we have the Si5351 chip onboard, but that probably should be on the main board. The SMD parts will be part of the PCB when sold.

To me, perhaps the most important thing we've done is bring out a bunch of pins , both digital and analog, for others to use. I hope the selected processor for such a project has a bunch available.

Jack, W8TEE



On Wednesday, August 15, 2018, 12:27:03 PM EDT, RCBoatGuy via Groups.Io <ijnfan-HamRadio= yahoo.com@groups.io> wrote:


Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC


 


 

W2CTX
 

The STM32F746NG is a board not a PC.  The raduino is a board.


https://www.st.com/en/evaluation-tools/32f746gdiscovery.html


On August 15, 2018 at 11:09 PM "Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

Still not a standalone system and requires a PC to process the signals. The cost's not bad if it were self-contained.

Jack, W8TEE
 


On Wednesday, August 15, 2018, 11:04:35 PM EDT, W2CTX <w2ctx@...> wrote:


Experimentally already exists in the form of code running in a STM32F746NG

driving https://www.hobbypcb.com/rs-hfiq.



On August 15, 2018 at 10:41 PM "Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

That's exactly where we hope to take it. I've had 4 SDR radios and enjoyed every one of them. However, I don't like being tethered to a PC or laptop. I'm hoping that, collectively, we can create a standalone SDR radio that doesn't cost an arm and a leg.

Jack, W8TEE
 


On Wednesday, August 15, 2018, 6:06:33 PM EDT, Dr. Flywheel <Dr.Flywheel@...> wrote:


By utilizing a Teensy 3.6 board you are opening the way for DSP-based generation and reconstruction of SSB and other signals. For example a pair of 45 deg. symmetrical Hilbert transforms can take care of precise phasing to effectively suppress the carrier and unwanted sideband. Such Hilbert filter can simultaneously replace the second IF crystal filter, if the conversion is brought down to audio frequencies. Being a programmable filter, the Hilbert transform can also provide variable bandwidth for the desired mode of operation. Further audio processing, like the audio band equalizer that you apparently implemented is just as icing on the cake. With appropriate CODEC, the Teensy 3.6 with its DMA capabilities, can easily support 192 kHz sampling rate, which means that in principle you could show FFT an waterfall diagrams in real time for a much wider bandwidth. This becomes essentially a hybrid SDR architecture at a very low cost.

--Ron   N7FTZ   

On Wed, Aug 15, 2018 at 10:19 AM Jack Purdum via Groups.Io <jjpurdum= yahoo.com@groups.io> wrote:
Carl:

Some very good ideas.
 

I'm showing the Rev 2 JackAl board here, partly to show what we done, but also to show the mistakes we made along the way. (We're doing
Inline image
the Rev 4 board now.) First, we've taken the buck converter off simply because it was too fragile when adjusting...far to easy to rip the adjusting screw right off the board. Second, the 7W audio amplifier (big IC on lower left) is stupid for the nano acres it takes plus its cost. Most users have powered speakers or can easily add them. We don't have a direct I2C connection, but we do have an SPI interface for the touch screen display. (Our display handles the video processing.) The rest are connections that work through the exiting µBITX headers, which would not be the same for a new design. Still, the above is less than 100mm x 100mm and parts are being taken off. Obviously, we have the Si5351 chip onboard, but that probably should be on the main board. The SMD parts will be part of the PCB when sold.

To me, perhaps the most important thing we've done is bring out a bunch of pins , both digital and analog, for others to use. I hope the selected processor for such a project has a bunch available.

Jack, W8TEE



On Wednesday, August 15, 2018, 12:27:03 PM EDT, RCBoatGuy via Groups.Io <ijnfan-HamRadio= yahoo.com@groups.io> wrote:


Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC


 


 

 


 


 

Christopher Miller
 

Isn't it a micro controller? I believe the op was referring to the need to use a pc to offload processing data.

W2CTX
 

The STM32 F7 runs all the software to drive the mentioned sdr radio without using a PC.

Has built-in psk31.


rOn

On August 15, 2018 at 11:33 PM Christopher Miller <djmalak2k6@...> wrote:

Isn't it a micro controller? I believe the op was referring to the need to use a pc to offload processing data.

Mike Short
 

I cut the trace on the raduino board and soldered the 4.7k resistor to the 5v and key pins. I may do the same with the other keyer resistors.

--
Mike
AI4NS

Jack, W8TEE
 

I was just going by what it said on the web site:

The I and Q signals must be provided/processed by external signal processing which could be a PC running Software Defined Radio software or a stand-alone digital signal processor

so something has to do the DSP, which is where the Teensy might come in.

Jack, W8TEE

On Wednesday, August 15, 2018, 11:43:36 PM EDT, W2CTX <w2ctx@...> wrote:


The STM32 F7 runs all the software to drive the mentioned sdr radio without using a PC.

Has built-in psk31.


rOn

On August 15, 2018 at 11:33 PM Christopher Miller <djmalak2k6@...> wrote:

Isn't it a micro controller? I believe the op was referring to the need to use a pc to offload processing data.

Glenn
 

I have one of these boards.  It requires a PC plus an external sound card.

There was talk of another board to replace the PC part and display etc, but I don't think anything has come of that.
glenn vk3pe

n2vdy
 

I am thinking of doing something similar but using an SBC for the DSP processing. I have a Raspberry Pi 3B+, an Odroid XU4, and an Amlogic S905 board to test with.

I have this sound card coming.
 https://www.kickstarter.com/projects/1250664710/audio-injector-ultra-2-sound-card?ref=discovery&term=Audio%20injector

You all will probably beat me to it though. I haven't had a lot of time to work on projects lately.

ajparent1/KB1GMX
 

On Wed, Aug 15, 2018 at 08:09 PM, Jack Purdum wrote:
Still not a standalone system and requires a PC to process the signals. 
Except its not totally true.  I have two radios that do not even have a mcu and the
I and Q are processed as analog, they are high performing radios that are
battery friendly.   Then again my Hallicrafters HT37 did it with tubes, and still does.

Further, I have the software running on Rpi3b (39$) and a 7" touch screen (39$)
for about a year now.  Not even original work as that was done on a Pi2 by
someone else. 

If that was not enough Kees had SDRtogo some two years ago using a 32mcu
I think was the PIC32.

PC required designs are out there.  Many are rejecting that and want fully
self contained and the low cost MCUs are there that can do that.

Allison

 

Jack, W8TEE
 

"Except its not totally true."

Gees, Allison, read what I said for once: I said the unit mentioned still required a PC, which it does. You then wander down some lane talking about other radios that don't require a PC, not the one I was referencing. I know there are SDR units out there that don't require a PC. Indeed, I have one (Elad Duo) which I like very much. Before you jump on my back for making an incorrect statement, it might be good to first see if the criticism is warranted. In this case, at least, it is not.

Jack, W8TEE


On Thursday, August 16, 2018, 10:23:23 AM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


On Wed, Aug 15, 2018 at 08:09 PM, Jack Purdum wrote:
Still not a standalone system and requires a PC to process the signals. 
Except its not totally true.  I have two radios that do not even have a mcu and the
I and Q are processed as analog, they are high performing radios that are
battery friendly.   Then again my Hallicrafters HT37 did it with tubes, and still does.

Further, I have the software running on Rpi3b (39$) and a 7" touch screen (39$)
for about a year now.  Not even original work as that was done on a Pi2 by
someone else. 

If that was not enough Kees had SDRtogo some two years ago using a 32mcu
I think was the PIC32.

PC required designs are out there.  Many are rejecting that and want fully
self contained and the low cost MCUs are there that can do that.

Allison

 

Jerry Gaffke
 

Oh boy, another argument!
Allow me to jump in here uninvited .....

Looking back through the thread I see the stuff included below where things went off the rails.

I'd agree with W2CTX that an STM32F746NG based thingie is not a PC, and
is perfectly capable of being included in a rig I can still easily pick up with one hand.

On the other hand, an old gumper like me is amazed at the power of such a device,
considerably more capable than what a PC was back when PC's were a hot topic. 

Jack did pipe up that a high end Teensy could well do the DSP processing
required to create a stand-alone radio.  So he knows a PC is not required.

So it seems everybody agrees.
Well, at least everybody agrees to argue.

Jerry



On Wed, Aug 15, 2018 at 08:24 PM, W2CTX wrote:

The STM32F746NG is a board not a PC.  The raduino is a board.

https://www.st.com/en/evaluation-tools/32f746gdiscovery.html

On August 15, 2018 at 11:09 PM "Jack Purdum via Groups.Io" <jjpurdum@...> wrote: 

Still not a standalone system and requires a PC to process the signals. The cost's not bad if it were self-contained. 
 
Jack, W8TEE 
 
On Wednesday, August 15, 2018, 11:04:35 PM EDT, W2CTX <w2ctx@...> wrote:

Experimentally already exists in the form of code running in a STM32F746NG

driving https://www.hobbypcb.com/rs-hfiq.

 

W2CTX
 

Seems everyone did not understand my post.  The SDR radio does require a PC and a sound card.

But I meant that you could hook the STM card to that radio and there is software to decode the IQ

and do psk31.


The STM card has 4" color touch screen, USB ports, uSD card, sound ports, and even built-in microphones

all for about $55.


rOn

On August 16, 2018 at 1:16 AM Glenn <glennp@...> wrote:

I have one of these boards.  It requires a PC plus an external sound card.

There was talk of another board to replace the PC part and display etc, but I don't think anything has come of that.
glenn vk3pe

ajparent1/KB1GMX
 

>>Except its not totally true.  I have two radios that do not even have a mcu and the
I and Q are processed as analog, they are high performing radios that are 
battery friendly.   Then again my Hallicrafters HT37 did it with tubes, and still does.<<

Jack, did you forget that item as the first paragraph.

And you double down with:

>>The I and Q signals must be provided/processed by external signal processing which could be a PC running Software Defined Radio software or a stand-alone digital signal processor <<

While it is absolutely true for that radio its not a absolute requirement.
Radios exist without a computer to do that! such as QRPlabs  QCX, The 4030 and few others.

My point being there is no requirent for a MPC to process I and Q and not any further off
the rails anymore than talking about SDR under the thread of HARMONICS.

Allison
Allison

 

ajparent1/KB1GMX
 

r0n,

It is generally accepted as true.  How about this?
SOFTRock Ensamble, usually used with computer!  Since I wanted portable I built up
two analog processsors (Nee KK7B R2pro) pu them in the audio path and Arduino in 
the path to run the Si70s and user interface (vfos and switching and stuff not DSP).
The result is |SDR|  where software is hardwired analog, without a PC (or a PC
substitute like a Rpi ).

If you have I and Q baseband audio this can be done. 

Allison

Jack, W8TEE
 

Allison:

You said my statement was "not totally true" when it was. In the second quote below, you imply that was my statement when in fact it was taken from the web site of the product being discussed. You then rambled on about something altogether different. Your statement about my quote was simply wrong and unwarranted. End of story, no more wasted bandwidth.

Jack, W8TEE


On Thursday, August 16, 2018, 11:11:24 AM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


>>Except its not totally true.  I have two radios that do not even have a mcu and the
I and Q are processed as analog, they are high performing radios that are 
battery friendly.   Then again my Hallicrafters HT37 did it with tubes, and still does.<<

Jack, did you forget that item as the first paragraph.

And you double down with:

>>The I and Q signals must be provided/processed by external signal processing which could be a PC running Software Defined Radio software or a stand-alone digital signal processor <<

While it is absolutely true for that radio its not a absolute requirement.
Radios exist without a computer to do that! such as QRPlabs  QCX, The 4030 and few others.

My point being there is no requirent for a MPC to process I and Q and not any further off
the rails anymore than talking about SDR under the thread of HARMONICS.

Allison
Allison

 

ajparent1/KB1GMX
 

Jack,

It is and it isn't.  Context and presentation is everything.
As to different, you implied a MPU or PC is a must.  I said
it is not a must and provided  examples.

As to off the rails. yes, you spoke the truth.  If I point out you were
already off the rails, that is conveniently forgotten.   This is BITX
not SDR, at this point we have been off the rails for a while.   
So the semantic games and  protests are meaningless.

I really don't care if XYZ SDR uses a PC or not.  Ihat it does reuire one in
my mind is a flaw as its not a radio if and until the PC is operational as until
then it  has no features or function.

Allison