Date   
Re: Fw: uBitx delivery

Ron
 

Should only a few days away from shipping. I ordered mine on 10 January and it was shipped on 7 March. Shipped via DHL and delivery is estimated for 14 March.

Ron
W5RKW

Re: Fw: uBitx delivery

Fr Richard R <rickocr2005@...>
 

Nick,
I paid for mine on 19 January, this is the response I received when I asked yesterday about shipping estimation:

"Your order for uBITX will be shipped in a week's time."


Fr Richard
WB8YXF



On Thursday, March 8, 2018, 1:31:47 PM EST, Nick Trollope <www.aplaceinfrance.com@...> wrote:


 
Hello chaps,
 
Paid for a ubitx on 14 January 18. Does anyone have any idea what delivery times are like at the moment?
 
Thanks
Nick
G4FAT
 

Re: uBITX Manager

Carlos E. Wenzel <Ik2yra@...>
 

 Dear Ian, 
I found this problem... 
my ubitx is Firm. 1.05_w    and Manager v0.99  both downloaded from your Site.
Error receive length = 0/1027
I'm doing something wrong??
Tks
Carlos ik2yra



2018-03-08 17:22 GMT+01:00 <davidaker@...>:

Thanks Ian, for some reason I was using 9600, changed it to 38400 and that did the trick.  Thanks for your patience.
David




--
Carlos Wenzel
ik2yra@...
+39-3284684518
Skype: IK2YRA

Re: w8tee vfo encoder issue

Doug W
 

Make sure you have the most recent version of Jack's manual.  There is a rev04 in the file section.

Re: Pulling Arduino data apart

Jack, W8TEE
 

Easy enough to do:

union {
  byte array[4];
  byte b;
  char c;
  int i;
  long L;
  float f;
} myUnion;

void setup() {
  int i;
  long val;

  myUnion.array[0] = 1;
  myUnion.array[1] = 2;
  myUnion.array[2] = 3;
  myUnion.array[3] = 4;

  Serial.begin(9600);

  for (i = 0; i < 4; i++) {
    Serial.print("array[");
    Serial.print(i);
    Serial.print("] = ");
    Serial.println(myUnion.array[i], HEX);
  }
  Serial.print("in HEX, L = ");
  Serial.print(myUnion.L, HEX);
  Serial.print(" or in decimal, L = ");
  Serial.println(myUnion.L);

  sendByte(val >> 24);
}

void sendByte(byte num)
{
  Serial.print("In sendByte() num = ");
  Serial.println(num, HEX);
}

void loop() {
}

The output is:

array[0] = 1
array[1] = 2
array[2] = 3
array[3] = 4
in HEX, L = 04030201 or in decimal, L = 67305985
In sendByte() num = 4

This shows that a long is stored in big endian format (i.e., most significant byte to least significant).

Jack, W8TEE


From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: BITX20@groups.io
Sent: Thursday, March 8, 2018 12:14 PM
Subject: Re: [BITX20] Pulling Arduino data apart

It would be interesting to see what the Arduino compiler does with this code:
    sendbyte(data32>>24);

That sort of thing is going to happen a lot in the code it sees, at least if I am writing it.
With optimization turned on, the compiler should recognize that everything remains
on byte boundaries and implement it as something very much like Jack's union trick. 
Should do this properly for big or little endian machines without me thinking about it.
No bit shifts.

Jerry



On Thu, Mar 8, 2018 at 08:57 am, Jerry Gaffke wrote:
If you have a 32 bit integer and want to send the 8 msb's over a serial link, do something like this:
    sendbyte(data32>>24);



Virus-free. www.avast.com

Re: Pulling Arduino data apart

Jerry Gaffke
 

Consider a serial link, perhaps a UART, we wish to send 32 bit integers over that link.
The spec for the serial link should define if those integers go over as big or little endian.
Let's assume the serial link spec says it is little endian, and that each character has 8 bits.

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.
However the C code on both ends must be aware of the integer size it is dealing with, be it 8,16,32 bits.
So the serial link spec may need to fully define the format of the data stream, not just say whether
it is big or little endian.

Plenty of C code out there that is not endian agnostic like that, and I'm fine with it.
Those 24 bit shifts are expensive if your compiler is turned down to dumb,
a typecast of an int32 pointer to an array of bytes may look like a more efficient way to code.
Most machines these days are little endian with 8/16/32/64 bit word sizes, and I'm fine
with code that assumes this is the case.  (There are some big endian machines though.)

But if you are trying to code for a machine that could be either big or little endian
or might have some weird word length in hardware, I'm of the opinion that the above
is the best way to do it.  If nothing else, it's very easy to read.
 
Endian-ness has even more repercussions when creating hardware.
I always found that working with the big-endian VME bus was a PITA,
the extra shifts were rather expensive back in the days of TTL,

It seems obvious at first glance, big-endian means we send over the most significant byte first,
and little endian means we send over the least significant byte first.
But implementation of this in a mixed environment can become a real head scratcher.
Especially if the implementation is not thoroughly thought out before coding starts.


>  Your sendbyte() example, the sendbyte(data32>>24) leaves the high byte for sending.
>  If you don't know the endian order, how do you know you didn't just rotate the data of interest onto the floor?

I don't quite follow.
sendbyte(data32>>24)   will always send the 8 msb's of that 32 bit word, regardless of what machine you are on.
I know I didn't rotate the data of interest onto the floor because I know that my data was in the 8 msb's of the 32 bit word. 

> The second example is no different. Indeed, since the shift right operator "backfills" with 0's
> and has higher precedence that the bitwise AND operator, you example always sends 0 to the function. Why bother? 

 
Hmm.  This second example?
    sendbyte((data32>>24)&0xff);
Only difference from the previous is that it makes it clear to the reader
that we are only interested in sending 8 bits.  And might save us from 
some weird bug if sendbyte() was not defined as an unsigned 8 bit int.
Looks fine to me.

Jerry


On Thu, Mar 8, 2018 at 10:34 am, Jack Purdum wrote:
OK, so what happens if you send an int from Allard's code to a 64 Intel I7? Compiler vendors are completely free to decide the byte order of all of their data types. My software company used to produced C programming tools (compilers, editors, assemblers, linkers) for both 8 bit and 16 bit machines. We made sure our Endians were the same, simply from a marketing standpoint. However, sending binary data from a 8 bit compiler to someone else's 16 bit compiler has no guarantee of working. Data structure packing and endian use is totally up to the compiler vendor. Indeed, there was one 8-bit MSDOS compiler vendor who chose to use -1 for NULL. The old XJ11 C standards committee made no restrictions on such things and the are defined as "implimentation dependent". That's why you should use NULL instead of 0 when checking string lengths. Now you could send the data as ASCII, but then you slow the transmission because values 0 through 255 only take 1 binary byte, but up to 3 ASCII bytes.
 
Your statement that "I can code all day in C without worrying about the big vs little endian" issue is only true at the source code level. If you are sending binary data, which is what I said in my post, you very definitely need to worry about the endian problem. As to 100 clock ticks, that seems high. An ldi assembler instruction take 3 clock cycles or 12 for a 32 bit long. Each rotate left (or right) is a single clock cycle, so I get 42 clock cycles to rotate a long off the map, and that includes the time to load it. So 0.000002625 of a second seems pretty quick Still, that's neither here nor there.
 
Your sendbyte() example, the sendbyte(data32>>24) leaves the high byte for sending. If you don't know the endian order, how do you know you didn't just rotate the data of interest onto the floor? The second example is no different. Indeed, since the shift right operator "backfills" with 0's and has higher precedence that the bitwise AND operator, you example always sends 0 to the function. Why bother?
 
Nope, there are times when you need to know the endian order and you can use a union to find it out. It can also be used to send binary data for a serial connection to a total different platform and still have it work. Knowing how to use a union is a good thing.
 
 

Re: Pulling Arduino data apart

Jerry Gaffke
 

The question was, is the compiler smart enough to emit assembly language 
that just grabs the appropriate bytes without messing with any bit shifts.
It should.
If you have the correct compiler optimization flags set.


On Thu, Mar 8, 2018 at 11:36 am, Jack Purdum wrote:
It would be interesting to see what the Arduino compiler does with this code:
    sendbyte(data32>>24);

Re: #uBiTx CW RF power out #ubitx

Bob
 

Sorry for the delay, but life does get in the way once in a while.

It looks like a lot of the ink went with the smoke but under the right light I could make out WX 16403HN.   The NTE7155 appears to be working ok. However, I am not going to give it the smoke test by shorting out the output.   If I am ordering parts from someone that also has the TDA2822 I will buy a couple and run a comparison.

 My next step is to quantitatively set the BFO.  With the equipment I have I should be able to get some repeatable numbers.

Thank for the feedback.  The spirit of Amateur Radio is alive and well :-)

Bob - KE7JL 

uBitx 321/3 is starting to come together #ubitx

Brien Wankel
 

I spent the last few nights taking measurements and designing a custom control panel for my uBitx. Last night I laser cut v1 of my design and starting putting it together. After getting it all mocked up and assembled i think the wiring of my USB port might run a bit too close to the heatsinks for my liking, so I suspect after a bit of break in i'll probably tweak this design a bit more and cut a new one. I still need to 3D print some knobs, might try to do that tonight. The main case is one of the Apache 1800 pelican knock-offs from Harbor Freight, the panel is laser cut/etched black acrylic. Full inside of enclosure section will be shielded/grounded with copper film after i have the final design nailed down. The vertical panel on the left has venting for the heat and a hole where i'll mount a grounding post. Cubby on the left side will be used for storage of paddle, headphones, mic, and power cables. Would love to hear any suggestions or words of warning if you have any. My main fear right now is the heatsinks. I'm thinking i'll be replacing the stock heatsinks with much larger pieces of 2" aluminum bar.



73,

Brien / K7XPO

Re: Pulling Arduino data apart

Neil Martinsen-Burrell
 

On Thu, Mar 8, 2018 at 1:42 PM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
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.
However the C code on both ends must be aware of the integer size it is dealing with, be it 8,16,32 bits.
So the serial link spec may need to fully define the format of the data stream, not just say whether
it is big or little endian.>  Your sendbyte() example, the sendbyte(data32>>24) leaves the high byte for sending.

>  If you don't know the endian order, how do you know you didn't just rotate the data of interest onto the floor?

I don't quite follow.
sendbyte(data32>>24)   will always send the 8 msb's of that 32 bit word, regardless of what machine you are on.
I know I didn't rotate the data of interest onto the floor because I know that my data was in the 8 msb's of the 32 bit word. 
connection to a total different platform and still have it work. Knowing how to use a union is a good thing.

It seems to me like Jerry is trying to point out that the left- and right-shift operators are endian-agnostic. They work in terms of the mathematically more-significant and less-significant directions without concern for the byte-order that an architecture uses to store its integers. so 256>>8 never gives a result of 0 on any architecture, even if the internal representation is 0x00 0x01.

-Neil N0FN

Re: Pulling Arduino data apart

Jack, W8TEE
 

I did provide an example that you can use to investigate it. If you're interested, just take the intermediate assembler file and take a look at it.

Jack, W8TEE



From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: BITX20@groups.io
Sent: Thursday, March 8, 2018 2:44 PM
Subject: Re: [BITX20] Pulling Arduino data apart

The question was, is the compiler smart enough to emit assembly language 
that just grabs the appropriate bytes without messing with any bit shifts.
It should.
If you have the correct compiler optimization flags set.


On Thu, Mar 8, 2018 at 11:36 am, Jack Purdum wrote:
It would be interesting to see what the Arduino compiler does with this code:
    sendbyte(data32>>24);


Re: uBITX - U1 Getting Fried - possible cause #ubitx

Bob
 

I smoked mine a week or so ago.  I replaced it with a NTE7155 that was in stock at Vetco, a local electronic supply store in the Seattle, Washington area. It is working fine.  I disconnected the output from the ring tab on the 3.5 mm speaker jack as a precaution. 

Bob - KE7JL

Re: Pulling Arduino data apart

Jack, W8TEE
 

The spec for the serial link should define if those integers go over as big or little endian.
...
So the serial link spec may need to fully define the format of the data stream, not just say whether
it is big or little endian.
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.

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






From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: BITX20@groups.io
Sent: Thursday, March 8, 2018 2:42 PM
Subject: Re: [BITX20] Pulling Arduino data apart

Consider a serial link, perhaps a UART, we wish to send 32 bit integers over that link.
The spec for the serial link should define if those integers go over as big or little endian.
Let's assume the serial link spec says it is little endian, and that each character has 8 bits.

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.
However the C code on both ends must be aware of the integer size it is dealing with, be it 8,16,32 bits.
So the serial link spec may need to fully define the format of the data stream, not just say whether
it is big or little endian.

Plenty of C code out there that is not endian agnostic like that, and I'm fine with it.
Those 24 bit shifts are expensive if your compiler is turned down to dumb,
a typecast of an int32 pointer to an array of bytes may look like a more efficient way to code.
Most machines these days are little endian with 8/16/32/64 bit word sizes, and I'm fine
with code that assumes this is the case.  (There are some big endian machines though.)

But if you are trying to code for a machine that could be either big or little endian
or might have some weird word length in hardware, I'm of the opinion that the above
is the best way to do it.  If nothing else, it's very easy to read.
 
Endian-ness has even more repercussions when creating hardware.
I always found that working with the big-endian VME bus was a PITA,
the extra shifts were rather expensive back in the days of TTL,

It seems obvious at first glance, big-endian means we send over the most significant byte first,
and little endian means we send over the least significant byte first.
But implementation of this in a mixed environment can become a real head scratcher.
Especially if the implementation is not thoroughly thought out before coding starts.

>  Your sendbyte() example, the sendbyte(data32>>24) leaves the high byte for sending.
>  If you don't know the endian order, how do you know you didn't just rotate the data of interest onto the floor?

I don't quite follow.
sendbyte(data32>>24)   will always send the 8 msb's of that 32 bit word, regardless of what machine you are on.
I know I didn't rotate the data of interest onto the floor because I know that my data was in the 8 msb's of the 32 bit word. 

> The second example is no different. Indeed, since the shift right operator "backfills" with 0's
> and has higher precedence that the bitwise AND operator, you example always sends 0 to the function. Why bother? 
 
Hmm.  This second example?
    sendbyte((data32>>24)&0xff);
Only difference from the previous is that it makes it clear to the reader
that we are only interested in sending 8 bits.  And might save us from 
some weird bug if sendbyte() was not defined as an unsigned 8 bit int.
Looks fine to me.

Jerry


On Thu, Mar 8, 2018 at 10:34 am, Jack Purdum wrote:
OK, so what happens if you send an int from Allard's code to a 64 Intel I7? Compiler vendors are completely free to decide the byte order of all of their data types. My software company used to produced C programming tools (compilers, editors, assemblers, linkers) for both 8 bit and 16 bit machines. We made sure our Endians were the same, simply from a marketing standpoint. However, sending binary data from a 8 bit compiler to someone else's 16 bit compiler has no guarantee of working. Data structure packing and endian use is totally up to the compiler vendor. Indeed, there was one 8-bit MSDOS compiler vendor who chose to use -1 for NULL. The old XJ11 C standards committee made no restrictions on such things and the are defined as "implimentation dependent". That's why you should use NULL instead of 0 when checking string lengths. Now you could send the data as ASCII, but then you slow the transmission because values 0 through 255 only take 1 binary byte, but up to 3 ASCII bytes.
 
Your statement that "I can code all day in C without worrying about the big vs little endian" issue is only true at the source code level. If you are sending binary data, which is what I said in my post, you very definitely need to worry about the endian problem. As to 100 clock ticks, that seems high. An ldi assembler instruction take 3 clock cycles or 12 for a 32 bit long. Each rotate left (or right) is a single clock cycle, so I get 42 clock cycles to rotate a long off the map, and that includes the time to load it. So 0.000002625 of a second seems pretty quick Still, that's neither here nor there.
 
Your sendbyte() example, the sendbyte(data32>>24) leaves the high byte for sending. If you don't know the endian order, how do you know you didn't just rotate the data of interest onto the floor? The second example is no different. Indeed, since the shift right operator "backfills" with 0's and has higher precedence that the bitwise AND operator, you example always sends 0 to the function. Why bother?
 
Nope, there are times when you need to know the endian order and you can use a union to find it out. It can also be used to send binary data for a serial connection to a total different platform and still have it work. Knowing how to use a union is a good thing.
 
 


Re: Pulling Arduino data apart

Jerry Gaffke
 

The example I would look at is 
    sendbyte(data32>>24);

I'm pretty sure that in most production environments, there would be no bit shifts in the assembly code.
With the default Arduino IDE, all bets are off.
Regardless, even if it did blindly do all those shifts, the way we handle the i2c interface
is an order of magnitude worse with regard to execution time.

Neil N0FN wrote:
> It seems to me like Jerry is trying to point out that the left- and right-shift operators are endian-agnostic

Indeed.
And a whole lot easier to read.
At least for me.

Jerry



On Thu, Mar 8, 2018 at 11:55 am, Jack Purdum wrote:
I did provide an example that you can use to investigate it. If you're interested, just take the intermediate assembler file and take a look at it.
 

Re: Pulling Arduino data apart

Jerry Gaffke
 

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.
    https://groups.io/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

Re: Pulling Arduino data apart

Jack, W8TEE
 

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: BITX20@groups.io
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.
    https://groups.io/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


Re: How to order a Raduino

Tim Gorman
 

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

Wiring of the CW jack

Tim Gorman
 

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: Fw: uBitx delivery

John KG9DK
 

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

Re: Wiring of the CW jack

Bob Bennett
 

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