Date   
Re: Modular uBitx - "Ex: Harmonics"

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

Re: Harmonic performance - SSB vs CW

Joe Puma
 

You send an audio signal of the digital mode over the mic input. If its not CW you’re communicating with you’ll be in SSB mode.

Joe
kd2nfc 

On Aug 15, 2018, at 6:32 PM, peder@... wrote:

Could you do a run on Digital?  We have a group planning on using this system to introduce hams to digital.  Does the digital approach simply use the CW system?

Peder, W7RPK

Re: Harmonics

Kees T
 

Here is another pretty clean LPF board .....I just sent the Gerber off, boards in a week.
- Uses 60mil RF lines over a full Ground plane for some level of impedance control.
- Uses 6 sets of the same 12V relays as used on the uBITX
- All relays have bifurcated and redundant contacts and switch both ends of the LPFs, normally grounded
- SMA Coax connector options on either end of the board.
- Board measures 99mm x 83mm
- Control is via switching 1 of 6 lines to ground with a remotely located rotary switch, can use a micro controlled mux later on
- LPF sockets are set up for Hans' "QRP Labs" LPFs, or make your own, or use the parts off the uBITX to build your own.
- Symmetrical LPFs can be mounted right side up or upside down, just watch the orientation (Grounds).
- If you are using T37 toroids, upside down LPFs should be about as tall as the relays and make a thin "sandwich".
- Gaps in the "top" wiring are continued as "jumpers" on the back of the board.

73 Kees K5BCQ

Re: Arduino Hangs

John (vk2eta)
 

Howard,

The i2c bus is normally driven from open collector outputs when writing to it, so it should not have internal pull up resistors used on the input.

The bus high voltage (+3.3V) should be driven by the external resistors on the Raduino.

Not sure what the default wire library does, but my diagnostic software disables the A4/A5 pull ups.

73, John

Re: uBitX CW bandwith

ajparent1/KB1GMX
 

No.

Re: Arduino Hangs

Tom, wb6b
 

The I2C pins are open collector and should be pulled up to 3.3 volts not 5 volts when used with the SI5351. The I2C bus is already pulled up to 3.3V in the uBITX, so additional pull-ups are not needed. The A4 and A5 pins should be programmed as INPUT so they don't overdrive the I2C bus.

Tom, wb6b

Re: Modular uBitx - "Ex: Harmonics"

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

Re: Sunday

El Calvo
 

My ubitx had the same output on 80m.  But after lowering the drive, power above 20m was too low. Changed the cap per Farhan sugestion to lower the gain on lower bands to 220pf. Now it gives around 12w on 80m, 15w on 40 and 20m.   6w on 10m. Drive is on the middle. 

On May 2, 2018 8:40 AM, <davesters@...> wrote:
Using my simple power meter I am showing 25 watts on 80m, 10 watts on 40m.  I have had voice qsos up to 1500 miles. The power level seems to drop if the antenna is out of tune. 

Re: BITX40 output power at 36 volts to the IRF510 #bitx40 #bitx40help

jah12@...
 

Have a look at a 25 Watt amp by VK3XU at http://www.philipstorr.id.au/radio/seven/five/25%20Watt%20Amp.pdf
Looks a bit simpler to build than the WA2EBY amp.
--
John VK6JAH

Re: Arduino Hangs

Howard Fidel
 

Tom:
I would expect what you say to be the case, but it is not what the hardware is doing. I am trying to understand why.

Howard

On 8/15/2018 10:40 PM, Tom, wb6b wrote:
The I2C pins are open collector and should be pulled up to 3.3 volts not 5 volts when used with the SI5351. The I2C bus is already pulled up to 3.3V in the uBITX, so additional pull-ups are not needed. The A4 and A5 pins should be programmed as INPUT so they don't overdrive the I2C bus.

Tom, wb6b


Re: Modular uBitx - "Ex: Harmonics"

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


 


 

Re: Modular uBitx - "Ex: Harmonics"

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


 


 

Re: uBitX CW bandwith

Kevin Timm
 

It's been discussed, IIRC the hypermite comes highly recommended


73
K5KDT
Kevin

Re: Modular uBitx - "Ex: Harmonics"

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


 


 

 


 


 

Re: Modular uBitx - "Ex: Harmonics"

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.

Re: Modular uBitx - "Ex: Harmonics"

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.

Re: Modular uBitx - "Ex: Harmonics"

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

Re: Modular uBitx - "Ex: Harmonics"

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.

Re: Arduino Hangs

John (vk2eta)
 

I am pretty sure that the default i2c wire library is enabling internal pullups.

Easy to check the code, but I don't have a pc with me right now.

But whatever it is doing in that regard it has been working reliably.

It would be interesting to have measures done on other working Raduinos.

John

Re: Arduino Hangs

Tom, wb6b
 

Hi Howard,

Here is a little more brute force pin setup I used recently. Don't know how you finally ended up setting the pin modes. I've probably missed a few comments in the thread. I assume the Nano will still accept an upload. Such as the blink program can upload and run. 


  pinMode(2, INPUT_PULLUP);
  pinMode(3, INPUT_PULLUP);
  pinMode(4, INPUT_PULLUP);
  pinMode(5, INPUT); // Frequency counter input pin
  pinMode(6, INPUT_PULLUP);
  pinMode(7, INPUT_PULLUP);
  pinMode(8, INPUT_PULLUP);
  pinMode(9, INPUT_PULLUP);
  pinMode(10, INPUT_PULLUP);
  pinMode(11, INPUT_PULLUP);
  pinMode(12, INPUT_PULLUP);
  pinMode(13, OUTPUT); // L led
  pinMode(A0, INPUT_PULLUP);
  pinMode(A1, INPUT_PULLUP);
  pinMode(A2, INPUT_PULLUP);
  pinMode(A3, INPUT_PULLUP);
  pinMode(A4, INPUT);  // If I2C bus. Must be INPUT
  pinMode(A5, INPUT);  // If I2C bus. Must be INPUT
  pinMode(A6, INPUT_PULLUP);
  pinMode(A7, INPUT_PULLUP);
Tom, wb6b