Re: swr_bridge.ino - Initial Success
Steve, We are not shipping with 1N4148s. The germanium diodes are getting scarce and the schottkey diodes are a bit expensive for the scratch builders. - f
On Wed, May 3, 2023, 7:31 AM Steve Beckman < n3sb@...> wrote: Farhan - the SWR Bridge board I have has two small potentiometers for adjusting the output voltage of the forward and reflected readings. The detector diodes are 1N5711 schottky diodes. Looks like you have selected 1N63 Germanium diodes for the detection circuitry in the V2. It would not be difficult to for me to swap the 1N5711 diodes out with 1N34 Germanium diodes if the voltage vs power curve difference becomes an issue.
I see a potential issue with the digispark module in that it's USB bootloader has a 1.5K pull-up resistor on the ADC3 input pin. I may need to have a #define in the Arduino code to change the ADC input from ADC3 to ADC1 if a digispark is being used. The other option would be to remove the 1.5K pull-up resistor from the board, and install one in a USB extender cable that's dedicated to programming the digispark. I'm not expecting that it will need to be programmed all that frequently, but the capability to do so needs to be maintained.
73; Steve, N3SB
|
Re: Ubitx V6 Nextion issues
I have tested all the traces on the board and all seem to be ok.? I have been starting to think it could be some thing with the si5351a.??
How do I go about testing the clocks?
Thanks
Spencer VA3SPN
|
Re: swr_bridge.ino - Initial Success
Farhan - the SWR Bridge board I have has two small potentiometers for adjusting the output voltage of the forward and reflected readings. The detector diodes are 1N5711 schottky diodes. Looks like you have selected 1N63 Germanium diodes for the detection circuitry in the V2. It would not be difficult to for me to swap the 1N5711 diodes out with 1N34 Germanium diodes if the voltage vs power curve difference becomes an issue.
I see a potential issue with the digispark module in that it's USB bootloader has a 1.5K pull-up resistor on the ADC3 input pin. I may need to have a #define in the Arduino code to change the ADC input from ADC3 to ADC1 if a digispark is being used. The other option would be to remove the 1.5K pull-up resistor from the board, and install one in a USB extender cable that's dedicated to programming the digispark. I'm not expecting that it will need to be programmed all that frequently, but the capability to do so needs to be maintained.
73; Steve, N3SB
|
Re: Second display on sBitx V2
#sBitx
Don't forget to load it up with the library of old 73s PDFs! - f
On Wed, May 3, 2023, 1:26 AM Bruce W4BRU < w4bru@...> wrote: You nailed it Scott. It does exactly what I want to do. As you noted, the key is connecting the micro-HDMI for the display/projector BEFORE bringing up power. I now have my vacation HF rig and my holiday computer complete with internet access, email, and office functions. What a great combination!
|
Re: swr_bridge.ino - Initial Success
Steve, The "polarity" of the L402 , the transformers is important for it to work properly. It will either add or subtract from the phase of L400 depending upon which way the winding goes. We are also experiencing some differences between germanium and silicon detection diodes. The calibration needs a single variable bridge_compensation. The code is in read_power() function of sbitx.c.? This is in the later commits. - f
On Wed, May 3, 2023, 6:18 AM Steve Beckman < n3sb@...> wrote: Dave - I opted to run the digispark from 3.3 Volts. The 3.3V, Ground, SCL, and SDA signals were all grabbed from the exposed pins at the RTC Module. Current drain is <10 mA. I still may put a separate 3.3V regulator on the board to reduce power dissipation in the existing 3.3V regulators.
The digispark module seems to be happy running at 3.3 Volts at 16.5 MHz. The ATTiny85 spec sheet indicates this is probably pushing the speed ratings a bit, so I'll have to try selecting the 8 MHz clock option in the Arduino IDE.
Anyway - without the digispark module connected, I get the expected "i2cbb.c: writing address failed at 8" messages on the console during transmit. With the module connected, those errors are no longer printed to the console during transmit. So the sBitx software is now getting a response to its commands on the i2c bus at address 8.
I can also tickle the ADC inputs on the digispark module with my finger, and cause the Power and SWR readings to change on the GUI - which means the little module is working!
That's enough for one evening. I have the SWR Bridge built and ready to wire in, so the next step is to get the Bridge interfaced and calibrated. After that it will be time to experiment with code fixes.
Looks like this will be a viable way to add Power and SWR measurement functionality to the sBitx DE.
73; Steve, N3SB
|
Re: swr_bridge.ino - Initial Success
Dave - I opted to run the digispark from 3.3 Volts. The 3.3V, Ground, SCL, and SDA signals were all grabbed from the exposed pins at the RTC Module. Current drain is <10 mA. I still may put a separate 3.3V regulator on the board to reduce power dissipation in the existing 3.3V regulators.
The digispark module seems to be happy running at 3.3 Volts at 16.5 MHz. The ATTiny85 spec sheet indicates this is probably pushing the speed ratings a bit, so I'll have to try selecting the 8 MHz clock option in the Arduino IDE.
Anyway - without the digispark module connected, I get the expected "i2cbb.c: writing address failed at 8" messages on the console during transmit. With the module connected, those errors are no longer printed to the console during transmit. So the sBitx software is now getting a response to its commands on the i2c bus at address 8.
I can also tickle the ADC inputs on the digispark module with my finger, and cause the Power and SWR readings to change on the GUI - which means the little module is working!
That's enough for one evening. I have the SWR Bridge built and ready to wire in, so the next step is to get the Bridge interfaced and calibrated. After that it will be time to experiment with code fixes.
Looks like this will be a viable way to add Power and SWR measurement functionality to the sBitx DE.
73; Steve, N3SB
|
Re: Simple off-the-shelf ATTiny85 burner
|
Hi Steve, With respect to the IO voltages, I believe that the sbitx peripheral devices (SI5351A, RTC) and the RPI4 are 3V3, so you should avoid driving 5V.
Generally I2C interfaces only drive logic ‘0’ and have pull-ups for the logic ‘1’, so you may be okay with a direct connection form the Digispark module.
However, to avoid any issues if you a programming whilst in circuit, you could use one of the cheap 2-channel MOSFET based level shifter modules. An example schematic of a 4-channel version is shown below.  For the few projects where I have used the ATtiny85, I use a USBASP (clone) programmer (Approx ?4.50 in the UK) and a simple homebrew board with a socket for the ATtiny.  Also, I agree it is best to avoid loading the 3V3 regulator that feeds the SI5351, since this may cause more noise to be generated on the clock outputs. Good luck with your experiments and updates. 73, Dave
|
Re: Simple off-the-shelf ATTiny85 burner
I was becoming concerned at the number of various programmers I was accumulating and keeping tabs on their operating software, so I recently bought a Xgecu T48 Universal programmer, after reading a review in Silicon Chip magazine. Certainly worth a look if you are in the market for a programmer. Very impressive device with the capability of programming more than 3500 different devices with more being added daily. One of my first uses was to read some very old legacy EPROM so that I could file their contents. Interestingly, it will also test most digital logic chips. Mine came with a wide range of optional interface sockets and include a board for doing the smd versions of the tinyAT85, as well as a socket for the DIP version. xgecofficialstore
Bill VK7MX
|
Dale
For a single station it might be better to use a series resonant notch filter.
--
Chuck, W5USJ
Point, Rains Co TX. EM22cv
|
This is probably a stupid question but:? Is the old GUI supposed to run with the new GUI on top of it?
Ron
|
Dave;
I agree with your concern. Blocking interrupts may cause an unacceptable delay in the i2c response from the attiny85. It needs to be tested.
My little digispark module is set to run at 16.5 MHz. Maybe those four variable assignments can be completed in a microsecond or so, and the i2c bus will never know anything happened.
Some instructions:
I added the link?? ?
to the additional boards manager URLs in my version 1.8.19 Arduino IDE, downloaded the attinycore? version 1.5.2 by Spence Konde using the boards manager, set the board type to attiny85 (micronucleus / digispark) hit the upload tool in the Arduino IDE, then plugged in the digispark module when the IDE prompted me to do so. The program is only using 1278 bytes or 19% of the code space (6586 bytes total available before programming) and 11% of the variable space. There's plenty of room for growth. Program sizes above are for Farhan's original code. I haven't added the interrupt blocking code or made any other changes yet.
This is going in a slightly different direction than Farhan is suggesting in his notes at the top of the .ino program. Looks like he might be using totally blank attiny85's. I'm starting with a digispark module that has a bootloader already installed.
I haven't tested it yet, just programmed it. So my "instructions" might be a total waste of time to follow. At least all the stars aligned, all the libraries needed were present, the compile completed successfully, and the code downloaded into the module!
The digispark module is set up for +5 Volts. I'll have to see if it will be happy running at +3.3 Volts. I'm not sure which option is best -- I could wire it up to +5 Volts, but then there's the remote possibility that the I/O pins might output +5 Volts on the same bus where the RTC, SI5351, and Raspberry Pi are connected, which are all 3.3 Volt devices. The other option is to connect the module to +3.3 Volts which (assuming it runs) would eliminate the possibility of 5 Volts on the i2c bus, but it does add an additional load to the 3.3 Volt regulator at the SI5351. And we know how that regulator will fail if something makes it unhappy.
73; Steve, N3SB
|
Re: Simple off-the-shelf ATTiny85 burner
That is what I wanted Dave. tks!
toggle quoted message
Show quoted text
On 5/2/23 23:42, stone_ridge_road wrote:
Maybe this?
73,
Dave?? AB7E
On 5/2/2023 10:19 AM, Rafael Diniz wrote:
As a computer scientist, I'm a bit lazy with the solder iron. Could anyone point me an off-the-shelf ATTiny85 burner?
I wish my v2 arrives soon.
: )
73,
Rafael PU2UIT
|
Couldn't we just do the read inside requestEvent()?
That would solve the problem definitely. Or use a mutex...
Rafael
toggle quoted message
Show quoted text
On 5/2/23 23:23, Rafael Diniz wrote: Peak detection should be in userland (raspberry), IMHO. But your idea is fantastic! Lets do it.
: )
On 5/2/23 22:55, Dave (G8PTN) wrote:
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave
|
Re: Simple off-the-shelf ATTiny85 burner
Maybe this?
73,
Dave?? AB7E
toggle quoted message
Show quoted text
On 5/2/2023 10:19 AM, Rafael Diniz wrote: As a computer scientist, I'm a bit lazy with the solder iron. Could anyone point me an off-the-shelf ATTiny85 burner?
I wish my v2 arrives soon.
: )
73,
Rafael PU2UIT
|
Peak detection should be in userland (raspberry), IMHO. But your idea is fantastic! Lets do it.
: )
toggle quoted message
Show quoted text
On 5/2/23 22:55, Dave (G8PTN) wrote:
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave
|
Re: Second display on sBitx V2
#sBitx
You nailed it Scott. It does exactly what I want to do. As you noted, the key is connecting the micro-HDMI for the display/projector BEFORE bringing up power. I now have my vacation HF rig and my holiday computer complete with internet access, email, and office functions. What a great combination!
|
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave?
?
|
Hi Rafael;
No Worries. We are fortunate to have all the source code at our fingertips so that we can review, improve, change, and learn from.
I have a couple Digispark modules laying around that might serve for code testing. They have a USB boot loader which makes for easy code downloading.
Power/SWR detection kits are available on ebay cheap. They look very much like what Diz used to offer.
Since we have all the source code, it would be easy to move from the attiny85 to an AVR module with more inputs like a Nano, and use the extra analog inputs to do things like read the power supply (battery) voltage, and the PA temperature. One could easily connect a potentiometer to an ADC input and use it for direct control of CW speed, or RF power. The extra digital inputs could be used to control the sending of pre-recorded CW or voice messages.
73; Steve, N3SB
|
Re: Ubitx V6 Nextion issues
For information a link to the Raduino schematic is attached for reference.
|
Chuck Carpenter
Bruce W4BRU