¿ªÔÆÌåÓý

  1. BITX20
  2. Messages
Expanded Topics Messages Polls
Date
Re: 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
Re: Pulling Arduino data apart

 

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

Jack Purdum
 

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: [email protected]
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: uBITX - U1 Getting Fried - possible cause #ubitx

 

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 Purdum
 

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: [email protected]
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: Pulling Arduino data apart

 

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
uBitx 321/3 is starting to come together #ubitx

 

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: #uBiTx CW RF power out #ubitx

 

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?
Re: 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: 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

Jack Purdum
 

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: [email protected]
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.

Re: w8tee vfo encoder issue

 

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

Carlos E. Wenzel
 

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

Fr Richard R
 

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

 

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: Pulling Arduino data apart

Jack Purdum
 

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.
Jack, W8TEE

From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: [email protected]
Sent: Thursday, March 8, 2018 11:57 AM
Subject: Re: [BITX20] Pulling Arduino data apart

You definitely need to be endian-aware when coding in assembly language.
But I can code all day in C without worrying about big vs little endian.

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);
I'm assuming sendbyte() accepts an 8 bit argument, so no need to explicitly strip off unused bits.
This might make it more obvious:
? ? sendbyte((data32>>24)&0xff);
That code is bulletproof in C, should work the same on a PDP-8 with 12 bit hardware?
as it does on the the latest stuff from Intel.? Unions will undoubtedly get packed differently
on a PDP-8, in case anybody still cares these days.? C does not specify that unions get packed
in any particular manner, that's true even on an 8/16/32/64 bit machine.

Unions almost always work, might be a good idea on a minimalist machine like the ATMega328P.
Shifting a 32 bit integer is relatively painful with an instruction set that can only shift an 8 bit word
left or right by one bit at a time.? However, while it might take 100 clock ticks to execute, the code to
shift a 32 bit word is instantiated only once as a function call, and 100 ticks happens much faster
than sending a single byte out through the I2C interface.? (100 ticks is a wild guess.)

If 100 ticks is too painful, then it's time to sack the Nano and move on to the $2 STM32 Blue Pill.

Take a look at the si5351 routines in Allard's code and on the uBitx.
Totally endian agnostic.
I'm looking forward to trying them out on a PDP-8 someday.

Jerry, KE7ER



On Thu, Mar 8, 2018 at 07:51 am, Jack Purdum wrote:
.....? If you are bit shifting or masking, you need to know the "Endian" order for the bytes. On an Arduino, you are given two functions: lowByte() and highByte() to allow you to extract the order to determine how the data are organized in an int. Knowing the byte order can be important, such as transferring binary data from one place to another over a serial link. But what if you are working with a long data type? The lowByte() and highByte() functions don't work since a long is 4 bytes. The solution is to use a C structure called a union. Think of the union as a buffer; a small chunk of memory. I think of it as a bucket, the size of which is determined by the biggest piece of data that will be stored in the union. For example: .....



Virus-free.

Re: How to order a Raduino

 

¿ªÔÆÌåÓý

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@...

RaduinoUMaxSheet.pdf
RaduinoUMaxSheet.pdf
RaduinoX7ASch.pdf
RaduinoX7ASch.pdf
RaduinoXSheet.pdf
RaduinoXSheet.pdf

Fw: uBitx delivery

 

¿ªÔÆÌåÓý

?
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: w8tee vfo board

 

C14 is a 100uF 25V electrolytic capacitor.? I used

Re: uBITX Firmware CEC Version Added WSPR function, I am looking for a beta tester. #ubitx

Carlos E. Wenzel
 

Hello Ian..
I have the same problem....

?"Error Receive Length = 0/1027"


2018-03-08 17:21 GMT+01:00 Ian Lee <kd8cec@...>:

All
uBITX Firmware CEC Version Added WSPR function, but?It is still a test level.
so, I am looking for a beta tester who has uBITX and knows how to use WSPR.

I used the following method to put the WSPR function in the small space of uBITX.
?- All settings required for WSPR transmission are pre-entered in uBITX.
?- Callsign, location(2alpha, 2 number), db and frequency information to be used for transmission are stored in uBITX.
?- Outdoors, uBITX and antenna are all you need to transmit WSPR with pre-entered information.

you do not need to make any modifications to your uBITX to use WSPR.
For more information, click on the link below.
(You can download uBITX Manager as firmware for WSPR.
Firmware is based on Cat Support uBITX Firmware CEC Version 1.04.)

--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
(my blog)




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

Beta WSPR.JPG

72981 - 73000 of 116849