Date   
Re: Completed my QCX #ubitx

pat griffin
 

Nice job.

Also, I see you are using the S meter and v 1.094 firmware as am I. Can you tell me the range in uBitx Manager you are seeing for the s-meter readings and if you are using the AGC circuit?

Thanks,

Pat AA4PG


Pat Griffin
http://www.cahabatechnology.com/aa4pg.html


From: BITX20@groups.io <BITX20@groups.io> on behalf of WD8WV <juddie.d.burgess@...>
Sent: Thursday, July 5, 2018 6:27:38 AM
To: BITX20@groups.io
Subject: Re: [BITX20] Completed my QCX #ubitx
 
Updated picture.

I added a momentary button just right if the VFO to access the menu options so I wouldn’t have to push the VFO, which I still can.  Also added a folding kickstand so when on the bench the front is elevated.
--
Judd, WD8WV

Re: Hijacked: C vs C++

Brian Bowling
 

How about making your programming safer and more robust?  Strcat() and strcpy() can be found at the root of so many buffer overflows. If you must use them at least use the 'n' versions strncpy() and strncat(). 

Brian

Re: Hijacked: C vs C++

Jack, W8TEE
 

That's not necessarily bulletproof, either, but a step in the right direction. Try this:

void setup() {

  char temp[5];
  int val = 0;
  Serial.begin(115200);
  while (!Serial);                // Necessary on some faster Arduinos, like the Due

  strncpy(temp, "12345", 5);
  Serial.print("temp = ");
  Serial.print(temp);
  Serial.print("# val = ");
  Serial.println(val);
}

void loop() {
}

It prints out "12345". The fact that it prints out the entire string means the string termination character is stored...where? The documentation for strncpy() states:

    No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered
    a null terminated C string (reading it as such would overflow).

Moral: The strn*() function don't guarantee  protection against buffer overflow. It simply means you're thinking about it.

Jack, W8TEE

On Thursday, July 5, 2018, 8:56:00 AM EDT, Brian Bowling <bowlingb@...> wrote:


How about making your programming safer and more robust?  Strcat() and strcpy() can be found at the root of so many buffer overflows. If you must use them at least use the 'n' versions strncpy() and strncat(). 

Brian

Re: Completed my QCX #ubitx

Art Olson
 

Judd

Great job. I added a button also. Easier to access menu. Where did you get your folding kickstand 

Art- N2AJO 


On Jul 5, 2018, at 8:55 AM, pat griffin <patgriffin@...> wrote:

Nice job.

Also, I see you are using the S meter and v 1.094 firmware as am I. Can you tell me the range in uBitx Manager you are seeing for the s-meter readings and if you are using the AGC circuit?

Thanks,

Pat AA4PG



From: BITX20@groups.io <BITX20@groups.io> on behalf of WD8WV <juddie.d.burgess@...>
Sent: Thursday, July 5, 2018 6:27:38 AM
To: BITX20@groups.io
Subject: Re: [BITX20] Completed my QCX #ubitx
 
Updated picture.

I added a momentary button just right if the VFO to access the menu options so I wouldn’t have to push the VFO, which I still can.  Also added a folding kickstand so when on the bench the front is elevated.
--
Judd, WD8WV

Re: Bitx40 75KHz Spurious, How to solve it. #bitx40

Skip Davis
 

Great work Akira, thanks for the pictures.

Skip Davis, NC9O

On Jul 5, 2018, at 05:12, jj1epe@... wrote:

Akira

Re: Easy, Inexpensive Cooling Fan, Excelway Case

Gary Anderson
 

Thanks Mike for highlighting my misunderstanding about how CW is implemented on the uBITX!
I should have reviewed the source code / schematics before posting, pretty obvious when I look at it :)
.. the difference between energizing the "TX" and the "CW-KEY"

Best Regards,
Gary

Re: Analog Smeter #smeter

JEAN-LUC F6HOY
 

Thanks for good adress.
 A little bit more expensive than from China (i am not a Prime member). And no shipping to France... Snif...
73

Re: Nextion display bezel

Art Olson
 

Gary

I selected PETG. looks great

73
Art N2AJO

On Jul 5, 2018, at 8:22 AM, Gary Hanson <grhanson@...> wrote:

Art Olson,

When ordering a bezel for the Nextion display, I noticed that 3D Hubs offered 8 different types of plastic options. I wondered what you used?


Gary Hanson

Re: Known issues on uBITX r4 #ubitx

Russ KG0BK
 

Agreed. My uBitx when set at 12.6 volts draws about 2.4 amps.

Re: Hijacked: C vs C++

Jerry Gaffke
 

I doubt this code:  "strncpy(temp, "12345", 5);" is storing a null anywhere.
You just happen to have had a handy zero somewhere in RAM to terminate it.
And the handy zero may or may not be from the "int val=0;"  .


I tried this under Ubuntu with gcc 4.8.4:

#################################
#include <stdio.h>
#include <string.h>
char bufa[6];
char z;
char bufb[4];
main() {
   strncpy(bufa, "hello", 6);
   z = 'Z';
   strncpy(bufb, "abcdefgh", 4);
   printf("%s %c %s \n", bufa, z, bufb);
}
########################################

That program gives the following output:     hello Z abcdhello 
 
Conclusions I draw from this:
    strncpy() works exactly as documented, it is copying over the 4 letters "abcd" and no terminating null character
    bufa[] follows (does not precede!) bufb[] in memory, and z is off somewhere else entirely.

The strncpy() function is much safer than strcpy() so long as the bytecount you give it agrees with the buffer size.
This is an excellent opportunity to use a #define:

#define BUFBSZ  4
char bufb[BUFBSZ];
   strncpy(bufb, "abcdefgh", BUFBSZ);

The fact that reading the string back goes beyond the end of the buffer allocated 
is not nearly so dangerous as having an overflow when writing.

All bets are off regarding exactly how the compiler is going to allocate RAM.
The Arduino IDE is also using gcc, so I'd expect similar results when programming a Nano.

Jerry, KE7ER


On Thu, Jul 5, 2018 at 06:20 am, Jack Purdum wrote:
That's not necessarily bulletproof, either, but a step in the right direction. Try this:
 
void setup() {

  char temp[5];
  int val = 0;
  Serial.begin(115200);
  while (!Serial);                // Necessary on some faster Arduinos, like the Due

  strncpy(temp, "12345", 5);
  Serial.print("temp = ");
  Serial.print(temp);
  Serial.print("# val = ");
  Serial.println(val);
}

void loop() {
}
 
It prints out "12345". The fact that it prints out the entire string means the string termination character is stored...where? The documentation for strncpy() states:
 
    No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered
    a null terminated C string (reading it as such would overflow).
 
Moral: The strn*() function don't guarantee  protection against buffer overflow. It simply means you're thinking about it.
 
Jack, W8TEE
 
. . .

Re: Hijacked: C vs C++

Arv Evans
 

Jerry and Jack

Might be interesting to dump the machine code resulting from that to see exactly what the
compiler is doing with strncpy versus strcpy. 

Wonder if anyone has tried alloc(), malloc(), and free() with the Arduino IDE?
Arv
_._


On Thu, Jul 5, 2018 at 9:49 AM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
I doubt this code:  "strncpy(temp, "12345", 5);" is storing a null anywhere.
You just happen to have had a handy zero somewhere in RAM to terminate it.
And the handy zero may or may not be from the "int val=0;"  .


I tried this under Ubuntu with gcc 4.8.4:

#################################
#include <stdio.h>
#include <string.h>
char bufa[6];
char z;
char bufb[4];
main() {
   strncpy(bufa, "hello", 6);
   z = 'Z';
   strncpy(bufb, "abcdefgh", 4);
   printf("%s %c %s \n", bufa, z, bufb);
}
########################################

That program gives the following output:     hello Z abcdhello 
 
Conclusions I draw from this:
    strncpy() works exactly as documented, it is copying over the 4 letters "abcd" and no terminating null character
    bufa[] follows (does not precede!) bufb[] in memory, and z is off somewhere else entirely.

The strncpy() function is much safer than strcpy() so long as the bytecount you give it agrees with the buffer size.
This is an excellent opportunity to use a #define:

#define BUFBSZ  4
char bufb[BUFBSZ];
   strncpy(bufb, "abcdefgh", BUFBSZ);

The fact that reading the string back goes beyond the end of the buffer allocated 
is not nearly so dangerous as having an overflow when writing.

All bets are off regarding exactly how the compiler is going to allocate RAM.
The Arduino IDE is also using gcc, so I'd expect similar results when programming a Nano.

Jerry, KE7ER


On Thu, Jul 5, 2018 at 06:20 am, Jack Purdum wrote:
That's not necessarily bulletproof, either, but a step in the right direction. Try this:
 
void setup() {

  char temp[5];
  int val = 0;
  Serial.begin(115200);
  while (!Serial);                // Necessary on some faster Arduinos, like the Due

  strncpy(temp, "12345", 5);
  Serial.print("temp = ");
  Serial.print(temp);
  Serial.print("# val = ");
  Serial.println(val);
}

void loop() {
}
 
It prints out "12345". The fact that it prints out the entire string means the string termination character is stored...where? The documentation for strncpy() states:
 
    No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered
    a null terminated C string (reading it as such would overflow).
 
Moral: The strn*() function don't guarantee  protection against buffer overflow. It simply means you're thinking about it.
 
Jack, W8TEE
 
. . .

THANKS #off_topic

Robert Ogburn
 

I feel honored to be a part of this community.  
Thanks to all who participate and share.
N5LXK Coahoma Texas
DM92ih

Re: Hijacked: C vs C++

Jerry Gaffke
 

I'm convinced that strcpy() and strncpy() do exactly as described in the documentation.
Either one could be written in 2 or 3 lines of code, there's not much going on.
    http://man7.org/linux/man-pages/man3/strncpy.3.html

And am confident alloc(), malloc(), and free() should work fine as well,
though there's hardly enough RAM in a Nano to bother.
If you do try using these, expect the unexpected when they collide with the stack.
Again, the code to implement these is quite trivial.

Those C++ calls?
Maybe somebody else cares.
I've got enough other stuff in the queue already to fill what few neurons I have left.
Memory allocation issues apply to domains well beyond that of gcc.

The moderately interesting thing here is that locations in RAM for global variables
are not necessarily allocated in the order we might have expected. 
This is also true of things like structures and unions.

Jerry, KE7ER




On Thu, Jul 5, 2018 at 08:59 am, Arv Evans wrote:
Might be interesting to dump the machine code resulting from that to see exactly what the
compiler is doing with strncpy versus strcpy. 

Wonder if anyone has tried alloc(), malloc(), and free() with the Arduino IDE?
What about new(), and delete() for C++ ?

Re: Easy, Inexpensive Cooling Fan, Excelway Case

Lee
 

I got from eBay a 40mm fan,$1.33, filter/fan guard, $1.43, and a temperature controlled fan controller, $3.58.  At room temperature the fan turns very slow.  You have to put your ear up to it to hear it.  




--
Lee - N9LO  "I Void Warranties"

 

Re: Nextion 3.2 Display

Allen Merrell
 

Tom

I almost had the 3.5 finished and my PC died. I have new PC now and I am in the process of recovering things from the old hard drive. I should have everything completed and the 3.5 posted in a few days.. This windows 10 I don't like, LOL, I like the 8.1 better.
--
Allen  Merrell

Re: Hijacked: C vs C++

Jack, W8TEE
 

The strncpy() function is much safer than strcpy() so long as the bytecount you give it agrees with the buffer size.

That's always been true, but is not what was originally said. The implication on the first go around was that using strncpy() protects you from buffer overflow. It does not. There is nothing in the strn*() functions that protect you from buffer overflow. Your statement recognizes that fact by saying that the programmer is responsible for buffer overflow, not the string library.

Jack, W8TEE

On Thursday, July 5, 2018, 11:59:39 AM EDT, Arv Evans <arvid.evans@...> wrote:


Jerry and Jack

Might be interesting to dump the machine code resulting from that to see exactly what the
compiler is doing with strncpy versus strcpy. 

Wonder if anyone has tried alloc(), malloc(), and free() with the Arduino IDE?
Arv
_._

On Thu, Jul 5, 2018 at 9:49 AM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
I doubt this code:  "strncpy(temp, "12345", 5);" is storing a null anywhere.
You just happen to have had a handy zero somewhere in RAM to terminate it.
And the handy zero may or may not be from the "int val=0;"  .


I tried this under Ubuntu with gcc 4.8.4:

#################################
#include <stdio.h>
#include <string.h>
char bufa[6];
char z;
char bufb[4];
main() {
   strncpy(bufa, "hello", 6);
   z = 'Z';
   strncpy(bufb, "abcdefgh", 4);
   printf("%s %c %s \n", bufa, z, bufb);
}
########################################

That program gives the following output:     hello Z abcdhello 
 
Conclusions I draw from this:
    strncpy() works exactly as documented, it is copying over the 4 letters "abcd" and no terminating null character
    bufa[] follows (does not precede!) bufb[] in memory, and z is off somewhere else entirely.

The strncpy() function is much safer than strcpy() so long as the bytecount you give it agrees with the buffer size.
This is an excellent opportunity to use a #define:

#define BUFBSZ  4
char bufb[BUFBSZ];
   strncpy(bufb, "abcdefgh", BUFBSZ);

The fact that reading the string back goes beyond the end of the buffer allocated 
is not nearly so dangerous as having an overflow when writing.

All bets are off regarding exactly how the compiler is going to allocate RAM.
The Arduino IDE is also using gcc, so I'd expect similar results when programming a Nano.

Jerry, KE7ER


On Thu, Jul 5, 2018 at 06:20 am, Jack Purdum wrote:
That's not necessarily bulletproof, either, but a step in the right direction. Try this:
 
void setup() {

  char temp[5];
  int val = 0;
  Serial.begin(115200);
  while (!Serial);                // Necessary on some faster Arduinos, like the Due

  strncpy(temp, "12345", 5);
  Serial.print("temp = ");
  Serial.print(temp);
  Serial.print("# val = ");
  Serial.println(val);
}

void loop() {
}
 
It prints out "12345". The fact that it prints out the entire string means the string termination character is stored...where? The documentation for strncpy() states:
 
    No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered
    a null terminated C string (reading it as such would overflow).
 
Moral: The strn*() function don't guarantee  protection against buffer overflow. It simply means you're thinking about it.
 
Jack, W8TEE
 
. . .

Re: Elmer in Atlanta GA with working BITx40 RFSignals Kit working

Hugo Boots
 

Vic,

I will give that file a try and measure the voltages.  Was your problem also
no output on transmit??

Did you use all the connectors supplied I had ONE left Over.

Hugo

On Wed, Jul 4, 2018 at 6:31 AM, Vic WA4THR via Groups.Io <vhklein@...> wrote:
There is a file here with the voltages to be expected for a BitX40. A common failure point is the Q13 transistor, which is what mine had before I installed the back-to-back diode mod. I actually found the problem watching a video from VK3YE. Google "VK3YE BitX40 repair".

=Vic=




--
Hugo

Re: Easy, Inexpensive Cooling Fan, Excelway Case

Dennis Yancey <bigbluedry@...>
 

You could put a cap in to hold the receive on for a couple of seconds like the old Browning Eagles did.. makes a “lovely” squeal to let everyone know you had pushed the PTT button.. goes great with that Roger Beep....lol

Re: Easy, Inexpensive Cooling Fan, Excelway Case

Dennis Yancey <bigbluedry@...>
 

Great approach. After all, it is temperature we are trying to dissipate. 

Re: Analog Smeter #smeter

bobolink
 

I was wondering how they simulated that old-timey glow.
“VU Meter with back light by filament”
It’s not simulated!
Now if they would just heat distress the meter face it could be from a HT32.

on order.