Re: RD16HHF1 power curve flattening...some
No worries, thank you Simon for the information.
I haven't noticed the feedback issue on mine.
Not sure where it coming from since Q6 is in-powered in RX.?
Worse case we can put an emitter follower npn on the supply side of the SSM2167 and extract the T/R line from the raduino (I have done that on mine) or bring the TX supply and regulate to 5V.
I will check that issue here.
73, John (VK2ETA)
|
Re: Raduino oscilators. 33mhz and 57mhz " . Documentation says one thing, but this is what I measured.
That's an excellent method to measure the frequency of the 25mhz oscillator.
If the receiver has sufficient low frequency audio response, you could monitor the speaker wires with a scope
and get sub hz accuracy when zero-beating.
I'll check my uBitx (tomorrow?), see how much warmup drift I can detect.
The 2.3khz drift (at 25mhz) you reported seems too large by a couple orders of magnitude.?
Jerry
toggle quoted message
Show quoted text
On Thu, Mar 8, 2018 at 07:55 pm, Michael Shreeve wrote:
I don't know if I responded to this. I thought I explained but then maybe not. What I have always done when there is no buffered output is 1 use a receiver and an "antenna" if you will, one that is near the raduino but not touching anything. 2 turn on a somewhat stable generator and, in my case right now, measure the generator frequency directly with a counter. I can hear that generator in the same receiver.. Zero beat the generator , which is being measured, with the 25 MHz signal emanating from the raduino. Turns out it did change as I indicated, merely from heating up. No direct coupling at all for this measurement. At least to the raduino. If I had a communications monitor I wouldn't need to measure the freq of the generator. Or some other stable generator source. Also, I need to try to determine just how accurate my counter is.?
|
Re: Raduino oscilators. 33mhz and 57mhz " . Documentation says one thing, but this is what I measured.
I don't know if I responded to this. I thought I explained but then maybe not. What I have always done when there is no buffered output is 1 use a receiver and an "antenna" if you will, one that is near the raduino but not touching anything. 2 turn on a somewhat stable generator and, in my case right now, measure the generator frequency directly with a counter. I can hear that generator in the same receiver.. Zero beat the generator , which is being measured, with the 25 MHz signal emanating from the raduino. Turns out it did change as I indicated, merely from heating up. No direct coupling at all for this measurement. At least to the raduino. If I had a communications monitor I wouldn't need to measure the freq of the generator. Or some other stable generator source. Also, I need to try to determine just how accurate my counter is.?
On Wed, Mar 7, 2018 at 10:12 PM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote: So did you measure the crystal directly?
If so, your probe likely modified the frequency a bit.
My calculation of 24.9991375 may be wrong for a number of reasons:
It assumed that your two readings of the three clocks were made while?
tuning through 10.0mhz in 50hz steps.? But we have since seen that there
is a bug in the code such that it would not make the LSB to USB transition while?
tuning in 50hz steps.? So not clear exactly what was going on there.
It assumes your rig was either uncalibrated (and thus si5351_vco==875.0mhz)
and that your probe on the crystal is not disturbing the crystal frequency.
Or that you are doing an si5351_setfreq() to one of the clock outputs of 25.0mhz and measuring that.
Jerry
On Wed, Mar 7, 2018 at 09:59 pm, Michael Shreeve wrote:
. . .
|
?Does anybody have a diagram or description of the mic wire up for the uBITX? I am looking for the mic itself, not the mic jack on the transceiver. Most of the mic's I have dealt with have the MIC+ going to one side of the electret and MIC- or ground routing through the PTT switch when it is closed, completing the circuit. Looking at the uBITX schematic and a mic wireup for an older version of BITX from several years ago on the forum, what I think I am seeing is that the sleeve is providing a constant ground to both the MIC- side of the electret and one side of the PTT switch. The tip connects a constant output to the other side of the PTT switch and the ring is providing a constant output to the MIC+ side of the electret. It almost looks like the electret is an "always on" state but the output is not utilized until the separate PTT circuit is completed. Any help would be appreciated.
|
Re: RD16HHF1 power curve flattening...some
Thanks John.?
I used the same board and similarly power from the regulated 5v line on the raduino. It also offboard and just inline with the mic line.
75k for compression and 1k for gating and 100k pot on output. At full output my audio was readable but distored based on the one audio check qso I had before I turned it down a bit.
I put a larger heatsink on the irf510 too to cater for the higher average output as the stock one was getting warm where previously it didnt.
A sideeffect of the mic being on all the time is that there is leakage through to the speaker and it causes some feedback if the mic is within 2 inches or so of the speaker. Not a big problem.
Sorry all for the off topic content!
Regards
Simon VK3ELH?
|
Re: RD16HHF1 power curve flattening...some
Hello Simon,
I used the small circuit board as found on eBay. A search of "SSM2167 Microphone Preamplifier Board Preamp COMP Compression Module DC 3V-5V" will show you the module I used.
I simply connected the input to the mic, added a 4.7Kohms resistor between the mic input and the 5VDC (taken from the Raduino) for biasing the electret and put a 10Kohms potentiometer in the output to adjust the power level to the mic preamp stage.?
So I didn't modify the uBitx board, simply inserted in the circuit. There is most likely too much gain which is reduced back with the output potentiometer?, but I haven't received any negative feedback about the compressor except when I pushed the output potentiometer?too high.
I have since removed the "R1" resistor and replaced it with a 51K Ohms resistor to get a 4/1 compression factor, up from the 2/1 as delivered. I haven't tested that on air yet.
On your Bitx40 what values resistors do you have for compression and noise gating?
Picture attached.
All the best,
73, John (VK2ETA)
|
Re: uBITX - U1 Getting Fried - possible cause
#ubitx
DUH!? I failed to read the datasheet!
Much obliged, sir.
|
Re: uBITX - U1 Getting Fried - possible cause
#ubitx
Good analysis. Since the current surge is of short duration, the 1.2W series resistor may be overkill.
I propose scaling the resistor to 2R2 (2.2 ohms) and the capacitor to 220uf...? I will enjpy your analysis.? At my age, arithmetic is advanced math!
|
Re: How to order a Raduino
Thanks, Mike. I just sent you some money for one of your assembled ubitx boards. I could assemble it myself but I just don't know where to get the time! tim ab0wr On Thu, 8 Mar 2018 14:07:47 -0800 "Michael Hagen" <motdog@...> wrote: I did it on an old Allard version. Use the library that is available,
and edit the prints to the LCDs.
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
Set up LCD and its I2C address.
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
My boards got a dedicated 4 Pin Molex for I2C at 5V.
Find the library and run some examples to get started.
73's Mike
On 3/8/2018 1:09 PM, Tim Gorman wrote:
Mike,
Is there code out there for utilizing your RaduinoUMax with an I2C
lcd?
I'm running a bunch of jumpers from the Raduino to the lcd and it's
a mess. Running four jumpers would be a lot cleaner installation.
tim ab0wr
On Thu, 8 Mar 2018 10:31:48 -0800
"Michael Hagen" <motdog@...> wrote:
I have the "Better" Rauinos for BitX and uBit.
I have sold over 50 to folks on this list.
Shipping to foreign countries is usually $15-20. I can give you a
shipping price from the US Post.
Take a look at attached documents.
73's Mike, WA6ISP
On 3/8/2018 9:40 AM, kir@... wrote:
Hi guys,
As I have an old Bitx40 with analog VFO, I would order a Raduino.
How can I do that ? found no info.
I do not have the correct email.
Can you help ?
Tnx and 73's from Felix/ON4KIR
|
Re: uBITX Firmware CEC Version Added WSPR function, I am looking for a beta tester.
#ubitx
Carlos
Thanks for trying test.
1.First, test with a communication program such as Ham radio deluxe or Wsjt-x to check the communication status.
2.Occasionally, such a problem can occur if the thickness of the USB cable is thin.
3.uBITX Firmware CEC Version may not be able to
CAT?
communicate when WSPR are used.
4.This is when you entered the WSPR menu.
please?Test and tell us your results.
Ian KD8CEC
Hello Ian.. I have the same problem....
?"Error Receive Length = 0/1027"
-- Best 73 KD8CEC / Ph.D ian lee kd8cec@...
(my blog)
|
Re: Pulling Arduino data apart
Agreed, we've wasted too much time on something not at the top of our priorities here. Anyone wishing to continue this discussion is welcome to send me a private message. In parting, I believe that once the data is in the CPU, in this case stored as a 32 bit integer in a register, endian-ness is not a factor.? This code?looks correct to me: Here's C code for machine A to send a 32 bit integer as a sequence of four bytes in little endian order:: ? ? sendbyte(data32);? sendbyte(data32>>8);? sendbyte(data32>>16);? sendbyte(data32>>24); And code for machine B to receive that 32 bit integer (assumes getbyte() returnes an unsigned 8 bit integer): ? ? data32=getbyte();? data32|=getbyte()<<8;? data32|=getbyte()<<16; data32|=getbyte<<24; This C code doesn't care if the machine it is on is big endian or little endian. ? An as I understand it, Jack disagrees, here's his argument:
My comment about putting bits on the floor meant that you had to know something about
the byte order, otherwise why are you interested only in the high byte. Your code:
? ? sendbyte((data32>>24)&0xff);
to send a byte works great if the data is big endian:?
????????01010101?00000000 00000000 00000000. ??????? // Yellow is the byte of interest
However, if you don't know the byte order and it is:?
????????00000000 00000000 00000000?01010101
Your code would throw the relevant data on the floor. Your code is only safe if you know
the order. A?union?is a simple way to determine that order.
Jerry, KE7ER
On Thu, Mar 8, 2018 at 12:53 pm, Jack Purdum wrote:
We've wasted enough bandwidth on this. I think unions are a great way to learn how data are organized for a given compiler and are well-worth knowing about. Anyone who doesn't think so can easily ignore them.
?
|
Re: Pulling Arduino data apart
Guys, I for one have enjoyed reading this exchange.? Good stuff?even though I had to brush away some cobwebs from the synapses.? Bits on the floor, assemblers, disassemblers. Those were the days.?
Three years ago we bought IBM Power8 running Red Hat and, IBM being IBM, it is big endian unlike the rest of Red Hat world.? We had to scramble with a few pieces of code and I hadn't though those thoughts in years.
Thanks
Pat? AA4PG
http://www.cahabatechnology.com
toggle quoted message
Show quoted text
They are agnostic on the host machine. That's correct. I was talking about a binary transfer between machines where the two may have different sized integers or ordering or both. The example I showed was from
a big endian to a little endian machine. When binary data comes into a program from some other source, the receiving machine doesn't necessarily know the order. So I could send a binary
long from the arduino that looks like this:
?01010101 00000000 00000000 00000000
but the host machine must figure out what those 4bytes mean. If it uses a little endian long, it would need to reverse the byte order for the
long to be properly represented on the receiving end.
The code that Allard wrote or your Si5351 code don't need to worry about it because all of the code is processed by the same GCC compiler using the same code generator. However, send an Arduino
long in binary format to a Desmet 8080 MSDOS compiler and I can guarantee you the data won't work.
We've wasted enough bandwidth on this. I think
unions are a great way to learn how data are organized for a given compiler and are well-worth knowing about. Anyone who doesn't think so can easily ignore them.
Jack, W8TEE
From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: [email protected]
Sent: Thursday, March 8, 2018 3:27 PM
Subject: Re: [BITX20] Pulling Arduino data apart
See my comments inline below.
On Thu, Mar 8, 2018 at 12:13 pm, Jack Purdum wrote:
Absolutely agree, which was what I was saying from the very start. Allard's code can be endian agnostic because it runs in a single known environment. I haven't looked at his code for
some time, but I don't know if there is anyplace in the code where he needs to break apart a basic data type.
If we are talking about the si5351bx routines I previously referenced that are in Allard's Bitx40 code,
they bust up some large integers and write them to specific bitfields of arbitrary size
in the i2c register set of the Si5351.? That's worse then just big/little endian, as those
fields are often not an even 8 bits.? I know, as I wrote the code.
? ???
Your statements below regarding how bit shifts work on a 32 bit integer
look wrong to me.? Integer operations like that are endian agnostic,
they don't care how that 32 bit register might get stored in main memory.
?
?
My comment about putting bits on the floor meant that you had to know something about the byte order, otherwise why are you interested only in the high byte. Your code:
?
? ? sendbyte((data32>>24)&0xff);
?
to send a byte works great if the data is big endian:
?
????????01010101 00000000 00000000 00000000. ??????? // Yellow is the byte of interest
?
However, if you don't know the byte order and it is:
?
????????00000000 00000000 00000000
01010101
?
Your code would throw the relevant data on the floor. Your code is only safe if you know the order. A
union is a simple way to determine that order.
?
Jack, W8TEE
|
Re: How to order a Raduino
I did it on an old Allard version.?
Use the library that is available, and edit the prints to the
LCDs.
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
Set up LCD and its I2C address.
LiquidCrystal_I2C lcd(0x27, 2, 1, 0,
4, 5, 6, 7, 3, POSITIVE);
My boards got a dedicated 4 Pin Molex
for I2C at 5V.
Find the library and run some examples
to get started.
73's Mike
On 3/8/2018 1:09 PM, Tim Gorman wrote:
Mike,
Is there code out there for utilizing your RaduinoUMax with an I2C lcd?
I'm running a bunch of jumpers from the Raduino to the lcd and it's a
mess. Running four jumpers would be a lot cleaner installation.
tim ab0wr
On Thu, 8 Mar 2018 10:31:48 -0800
"Michael Hagen" <motdog@...> wrote:
I have the "Better" Rauinos for BitX and uBit.
I have sold over 50 to folks on this list.
Shipping to foreign countries is usually $15-20. I can give you a
shipping price from the US Post.
Take a look at attached documents.
73's Mike, WA6ISP
On 3/8/2018 9:40 AM, kir@... wrote:
Hi guys,
As I have an old Bitx40 with analog VFO, I would order a Raduino.
How can I do that ? found no info.
I do not have the correct email.
Can you help ?
Tnx and 73's from Felix/ON4KIR
--
Mike Hagen, WA6ISP
10917 Bryant Street
Yucaipa, Ca. 92399
(909) 918-0058
PayPal ID "MotDog@..."
Mike@...
|
Re: Wiring of the CW jack
|
Re: Wiring of the CW jack
Found the answer in the archives. Picture is wrong. tim ab0wr On Thu, 8 Mar 2018 15:13:16 -0600 "Tim Gorman" <tgorman2@...> wrote: All,
I am finally getting to finally wiring up my ubitx (takes a while
getting everything done with about 15 min per day!).
In looking at the wiring instructions as compared to the pictures the
instructions say to wire the blue wire from the digital connector to
the tip lead of the jack. But in looking at the picture in the
instructions I swear the wiring is going to the ring tab.
Am I blind?
tim ab0wr
|
Re: Wiring of the CW jack
I am finding similar problems with following the instructions as the photos dont show enough angles. I have looked for Youtube videos but the one that ¡®looks¡¯ that it might help has more segments that a graduate EE course! It is like the author is using the video to impress his girlfriend¡¯s parents, not help you build this.I am kind of winging it. If you hear the fire engines, its here ;-)
NZ2Z
|
Nick,
I ordered mine on Jan. 8th,got a heads up from PayPal?yesterday that it has been shipped.? Based on that I would say about 2 months from the day you order to ship date. ?
john kg9dk
|
All,
I am finally getting to finally wiring up my ubitx (takes a while
getting everything done with about 15 min per day!).
In looking at the wiring instructions as compared to the pictures the
instructions say to wire the blue wire from the digital connector to
the tip lead of the jack. But in looking at the picture in the
instructions I swear the wiring is going to the ring tab.
Am I blind?
tim ab0wr
|
Re: How to order a Raduino
Mike, Is there code out there for utilizing your RaduinoUMax with an I2C lcd? I'm running a bunch of jumpers from the Raduino to the lcd and it's a mess. Running four jumpers would be a lot cleaner installation. tim ab0wr On Thu, 8 Mar 2018 10:31:48 -0800 "Michael Hagen" <motdog@...> wrote: I have the "Better" Rauinos for BitX and uBit.
I have sold over 50 to folks on this list.
Shipping to foreign countries is usually $15-20. I can give you a
shipping price from the US Post.
Take a look at attached documents.
73's Mike, WA6ISP
On 3/8/2018 9:40 AM, kir@... wrote:
Hi guys,
As I have an old Bitx40 with analog VFO, I would order a Raduino.
How can I do that ? found no info.
I do not have the correct email.
Can you help ?
Tnx and 73's from Felix/ON4KIR
|
Re: Pulling Arduino data apart
They are agnostic on the host machine. That's correct. I was talking about a binary transfer between machines where the two may have different sized integers or ordering or both. The example I showed was from a big endian to a little endian machine. When binary data comes into a program from some other source, the receiving machine doesn't necessarily know the order. So I could send a binary long from the arduino that looks like this:
?01010101 00000000 00000000 00000000
but the host machine must figure out what those 4bytes mean. If it uses a little endian long, it would need to reverse the byte order for the long to be properly represented on the receiving end.
The code that Allard wrote or your Si5351 code don't need to worry about it because all of the code is processed by the same GCC compiler using the same code generator. However, send an Arduino long in binary format to a Desmet 8080 MSDOS compiler and I can guarantee you the data won't work.
We've wasted enough bandwidth on this. I think unions are a great way to learn how data are organized for a given compiler and are well-worth knowing about. Anyone who doesn't think so can easily ignore them.
Jack, W8TEE
From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: [email protected]
Sent: Thursday, March 8, 2018 3:27 PM
Subject: Re: [BITX20] Pulling Arduino data apart
See my comments inline below. On Thu, Mar 8, 2018 at 12:13 pm, Jack Purdum wrote:
Absolutely agree, which was what I was saying from the very start. Allard's code can be endian agnostic because it runs in a single known environment. I haven't looked at his code for some time, but I don't know if there is anyplace in the code where he needs to break apart a basic data type.
If we are talking about the si5351bx routines I previously referenced that are in Allard's Bitx40 code, they bust up some large integers and write them to specific bitfields of arbitrary size in the i2c register set of the Si5351.? That's worse then just big/little endian, as those fields are often not an even 8 bits.? I know, as I wrote the code. ? ?? /g/BITX20/message/28977? Your statements below regarding how bit shifts work on a 32 bit integer look wrong to me.? Integer operations like that are endian agnostic, they don't care how that 32 bit register might get stored in main memory.
?
?
My comment about putting bits on the floor meant that you had to know something about the byte order, otherwise why are you interested only in the high byte. Your code:
?
? ? sendbyte((data32>>24)&0xff);
?
to send a byte works great if the data is big endian:
?
????????01010101 00000000 00000000 00000000. ??????? // Yellow is the byte of interest
?
However, if you don't know the byte order and it is:
?
????????00000000 00000000 00000000 01010101
?
Your code would throw the relevant data on the floor. Your code is only safe if you know the order. A union is a simple way to determine that order.
?
Jack, W8TEE
|
Michael Shreeve
Robert Ogburn
Bob Bennett
John KG9DK