开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. BITX20
  2. Topics

Calibration route

College Professor Simon Thompson
 

Hi


Everything was working until I tried to calibrate the Bitx40. I grounded the red wire from the Raduino, the calibration routine launched, I zero beat the received frequency, disconnected the ground path. And then the radio stated to motorboat, and the screen will not stop displaying "Calibration: Set to Zero Beath: XXXX" and then the message changes to "Calibration: Set Offest: XXXX," and then the radio starts motor boating and there is a shrill tone coming out of the speaker. I disconnected everything, the reloaded the sketch and library, and reconnected everything, but the same message comes up when I restart it.


Any ideas?
 

Check the main supply voltage, make sure it is within between 10 and 13 volts (ideally 12) when the rig is misbehaving.?

Check the current from the main supply voltage, should be around 150 ma when receiving.

The audio amp can oscillate if the speaker impedance is less than 8 ohms, maybe try a 10 ohm resistor in series with your speaker.

Check the 5v supply on the Raduino. ?One place to look is at the tuning pot, the two outside lugs are ground and 5 volts (the middle lug is the tuning voltage). ?

Is the 3 pin LM7805 hanging off the Raduino getting too hot to touch? ?It shouldn't. ?Anything else getting hot?

I suggest you unplug the push-to-talk switch from the Bitx40 board for now, don't want to be accidently transmitting while going through these first steps debugging the receiver. ?Also unplug the PA-12v connector, as that puts 12v on the heat sink of the final transistor and you really don't want to short that to ground.

Check the voltage of the red calibration wire, it should be up near 5 volts when not connected to ground. ?Any chance this wire got shorted to something, perhaps the IRF510 heat sink??

Sounds like two problems. ?You could disconnect the Raduino from the rig and power it from 12v, see if the display and tuning knob work properly. ?

Then apply power to the main board (no Raduino), it won't receive without a VFO but that motorboating and shrill tone are likely in the audio amp section and probably don't need the VFO to happen. ?They could also be due to trouble with the wiring around the volume control pot.



On Sun, Mar 26, 2017 at 06:09 pm, College Professor Simon Thompson wrote:

Everything was working until I tried to calibrate the Bitx40. I grounded the red wire from the Raduino, the calibration routine launched, I zero beat the received frequency, disconnected the ground path. And then the radio stated to motorboat, and the screen will not stop displaying "Calibration: Set to Zero Beath: XXXX" and then the message changes to "Calibration: Set Offest: XXXX," and then the radio starts motor boating and there is a shrill tone coming out of the speaker. I disconnected everything, the reloaded the sketch and library, and reconnected everything, but the same message comes up when I restart it.

?
 

This can get very complicated very fast.

Essentially, I think when you disconnected everything and reloaded, You either did not reload,
or you reloaded the same hex file as before. But that hex file is one that was saved by default
during verification. For some reason it has a bug. The default behavior of the IDE on a new upload
is to use the same hex file as before, if there have been no changes to the source.

To find out some info, when you start the IDE, go to "file" and "preferences"
menus. Check "verbose output" for both compile and upload. These are not
on by default.

Restart the IDE and recompile. Do not upload. Look at the black window at the bottom
of the window. It has a long list of messages. Most of them will be quite meaningless, but
near the bottom is a set of 8 or 10 showing the final compiler action; most important here
is the fact that it shows one where those files are found. The default is

"users/[username]/AppData/Local/Temp/[a long list of numbers]".

That is where the temporary files are stored, including the hex and eep files. They are in a subdirectory with a long string of numbers
for a name. If you have done compiling of different source files, there may be several of these number subdirectories.
Incidentally, if you want to save a known good hex file, here is whereit is; it is supposed to be deleted when the IDE is closed,
so copy it to a good location (your sketchbook?).

You can go to that ".../Temp/" subdirectory and delete everything there. The IDE is supposed
to do that when it closes, but it doesn't always. That way, one can insure that a new compilation
really is new. Not everything in Temp wants to be deleted, If it is in use by the system, a file cannot be deleted;
merely skip it. Note that the Arduino IDE must be closed for you to delete files related to that program.

Now AppData is normally a hidden file; you may not be able to find it. Go to the control panel under "system"
and check "show hidden files" if that is the case. Beware; you may think you have found it but the system will
not let you go there. That is a pointer to the real subdirectory and is quite useless to the user. Ignore it. I usually get
there by stating at the Windows directory under "computer"and going in there.

Now you have some data to work with. If there is a new compilation, it will have a new number subdirectory and
that will be listed in the verbose window. You can start to compare and find versions of your compiles, if they exist.
Make sure that the new uploaded file is the one you are compiling, and not one of the old ones (which don't work!).
Now you can make changes and know that they are applied. And all of these number subdirectories are dated and time-marked.
So you know their ordering. Start there.

The other most common problem with upload is the assertion of the reset function at the start. This is programmer
and board version related and can sometimes be quite vexing. But if you can do a successful upload, it most likely is
not a problem in your case.

This is Windows, of course; Linux is a little different but the files will be in a subdirectory under "home/[username].
The same basic rules apply.

There are LOTS of other reasons for this behavior; sometimes it aint easy.

Hope this helps (a little bit. Hi.).

john
AD5YE
College Professor Simon Thompson
 

Ok. I have quite a lot of work to do, but it will be a few days before I can get to it. I did a few tests and, ominously, I got zero volts from the Arduino red wire. I suspect that, somehow, I damaged the final transistor, but I do not understand how that would lock the Raduino into a routine. I will work on the Raduino issue, and also work on the board solutions. I will report back.

On Mar 26, 2017, at 7:56 PM, John Backo via Groups.Io <iam74@...> wrote:

This can get very complicated very fast.

Essentially, I think when you disconnected everything and reloaded, You either did not reload,
or you reloaded the same hex file as before. But that hex file is one that was saved by default
during verification. For some reason it has a bug. The default behavior of the IDE on a new upload
is to use the same hex file as before, if there have been no changes to the source.

To find out some info, when you start the IDE, go to "file" and "preferences"
menus. Check "verbose output" for both compile and upload. These are not
on by default.

Restart the IDE and recompile. Do not upload. Look at the black window at the bottom
of the window. It has a long list of messages. Most of them will be quite meaningless, but
near the bottom is a set of 8 or 10 showing the final compiler action; most important here
is the fact that it shows one where those files are found. The default is

"users/[username]/AppData/Local/Temp/[a long list of numbers]".

That is where the temporary files are stored, including the hex and eep files. They are in a subdirectory with a long string of numbers
for a name. If you have done compiling of different source files, there may be several of these number subdirectories.
Incidentally, if you want to save a known good hex file, here is whereit is; it is supposed to be deleted when the IDE is closed,
so copy it to a good location (your sketchbook?).

You can go to that ".../Temp/" subdirectory and delete everything there. The IDE is supposed
to do that when it closes, but it doesn't always. That way, one can insure that a new compilation
really is new. Not everything in Temp wants to be deleted, If it is in use by the system, a file cannot be deleted;
merely skip it. Note that the Arduino IDE must be closed for you to delete files related to that program.

Now AppData is normally a hidden file; you may not be able to find it. Go to the control panel under "system"
and check "show hidden files" if that is the case. Beware; you may think you have found it but the system will
not let you go there. That is a pointer to the real subdirectory and is quite useless to the user. Ignore it. I usually get
there by stating at the Windows directory under "computer"and going in there.

Now you have some data to work with. If there is a new compilation, it will have a new number subdirectory and
that will be listed in the verbose window. You can start to compare and find versions of your compiles, if they exist.
Make sure that the new uploaded file is the one you are compiling, and not one of the old ones (which don't work!).
Now you can make changes and know that they are applied. And all of these number subdirectories are dated and time-marked.
So you know their ordering. Start there.

The other most common problem with upload is the assertion of the reset function at the start. This is programmer
and board version related and can sometimes be quite vexing. But if you can do a successful upload, it most likely is
not a problem in your case.

This is Windows, of course; Linux is a little different but the files will be in a subdirectory under "home/[username].
The same basic rules apply.

There are LOTS of other reasons for this behavior; sometimes it aint easy.

Hope this helps (a little bit. Hi.).

john
AD5YE
 

Grounding the red wire causes the menu for calibration to appear. If the red wire is attached to a pin on the Nano,
that means that pin is always at zero volts. But that is what the program expects to start the calibration
routine. Without the wire "grounded", the pin should be high, or at 5v. It is likely that something happened to the
programming which caused this internally -- but there could be a physical reason for the zero volts. Look for that first.

john
AD5YE
College Professor Simon Thompson
 

I might film what is happening and upload it. Maybe that would provide others with a better sense of the issues.

On Mar 26, 2017, at 9:52 PM, John Backo via Groups.Io <iam74@...> wrote:

Grounding the red wire causes the menu for calibration to appear. If the red wire is attached to a pin on the Nano,
that means that pin is always at zero volts. But that is what the program expects to start the calibration
routine. Without the wire "grounded", the pin should be high, or at 5v. It is likely that something happened to the
programming which caused this internally -- but there could be a physical reason for the zero volts. Look for that first.

john
AD5YE
 

"ominously, I got zero volts from the Arduino red wire."

P.S.

With the calibration pin at zero volts, that would also cause the program to loop. It
looks at the pin for zero volts, finds it, calls the routine to calibrate, gets the new
value and returns, The "loop" section then begins again, checking the pin along the way,
finding it grounded and does the whole thing over...and over...

john
AD5YE
College Professor Simon Thompson
 

But it’s doing it whether the pin is grounded or not. That’s part of the mystery.

On Mar 26, 2017, at 9:59 PM, John Backo via Groups.Io <iam74@...> wrote:

"ominously, I got zero volts from the Arduino red wire."

P.S.

With the calibration pin at zero volts, that would also cause the program to loop. It
looks at the pin for zero volts, finds it, calls the routine to calibrate, gets the new
value and returns, The "loop" section then begins again, checking the pin along the way,
finding it grounded and does the whole thing over...and over...

john
AD5YE
 

Tie it high, a floating input can be influenced by the adjacent pin(s).

?

?

On 2017-03-27 04:00 PM, College Professor Simon Thompson wrote:

But it’s doing it whether the pin is grounded or not. That’s part of the mystery.
On Mar 26, 2017, at 9:59 PM, John Backo via Groups.Io <iam74@...> wrote: "ominously, I got zero volts from the Arduino red wire." P.S. With the calibration pin at zero volts, that would also cause the program to loop. It looks at the pin for zero volts, finds it, calls the routine to calibrate, gets the new value and returns, The "loop" section then begins again, checking the pin along the way, finding it grounded and does the whole thing over...and over... john AD5YE

 

That may be a key observation. The program expects that pin to be at 5v UNLESS the red wire
is grounded. It is the transition from 5v to 0v that causes the call to the calibration routine. If
the pin itself is always at 0v, then the repeated calling of the routine would take place. The question then is:
Is the pin itself at 0v? And why? Remember, removing the red wire from ground will cause the pin to revert to its
original condition...presumably. I.e., the pin will float high unless grounded.

Incidentally, the other symptoms of audio, etc. may be ancillary to the fact that the loop is taking place. It is
going through some other routines as well.

john
AD5YE
 

Try using a 220 ohm resistor to high instead of straight to +V in case there is a short somewhere on the board causing the error. Creating a +V to GND without any resistance at all is a quick way to burn a trace or two.

On 3/27/2017 1:05 AM, Darryl Harvey wrote:
Tie it high, a floating input can be influenced by the adjacent pin(s).
 

Darryl's suggestion is good. Take a wire and temporarily apply 5v
to the pin. Careful! Watch out for grounding. Been there; done that.
If the loop stops, then there is a problem with the pin;
if not, then the program may be corrupted in some way. Either way.
it looks like back to ground zero and clear everything and start over.

Try loading the Blinkie program and see if you get a flashing led. That will
say the programming procedure is good -- but it will tell you little or nothing
about the condition of the pins other than pin13. If you load a known good program
and the condition reappears, the Nano itself is suspect.

john
AD5YE
 

To elaborate on this topic;

Source: ?http://electronics.stackexchange.com/questions/83133/arduino-digitalread-reading-wrong

What you have is called a?Floating?pin. Digital Input pins are very sensitive to change, and unless positively driven to one state or another (High or Low), will pick up stray capacitance from nearby sources, like breadboards, human fingers, or even the air. Any wire connected to it will act like a little antenna and cause the input state to change. And I mean any wire, the trace on the board, the wire to the breadboard, the breadboard pin, even the metal pin of the IC itself.

This is refereed to in the Arduino reference page:

If the pin isn't connected to anything, digitalRead() can return either HIGH or LOW (and this can change randomly).

If you look at the?:

This also means however, that input pins with nothing connected to them, or with wires connected to them that are not connected to other circuits, will report seemingly random changes in pin state, picking up electrical noise from the environment, or capacitively coupling the state of a nearby pin.

Often it is useful to steer an input pin to a known state if no input is present. This can be done by adding a pullup resistor (to +5V), or a pulldown resistor (resistor to ground) on the input, with 10K being a common value. There are also convenient 20K pullup resistors built into the Atmega chip that can be accessed from software. These built-in pullup resistors are accessed in the following manner.

pinMode(pin, INPUT); // set pin to input digitalWrite(pin, HIGH); // turn on pullup resistors

These weak pull resistors force the input pin state into a known state, and are easily overwritten by stronger input voltages, like a direct connection to ground or +5v.


So tie it high (Via a resistor) to the 5V rail.


Rgds,
Darryl
College Professor Simon Thompson
 

开云体育

Hi Darryl

Please tell me precisely how I am to do this.

What pin do I connect to the 5 v rail? What does “tie it high” mean? Where is the 5 v rail? What resistor (resistance and wattage) should I use??

It would be helpful if you could describe the procedure step by step.

On Mar 26, 2017, at 10:39 PM, Darryl Harvey <darryl@...> wrote:

To elaborate on this topic;

Source: ?

What you have is called a?Floating?pin. Digital Input pins are very sensitive to change, and unless positively driven to one state or another (High or Low), will pick up stray capacitance from nearby sources, like breadboards, human fingers, or even the air. Any wire connected to it will act like a little antenna and cause the input state to change. And I mean any wire, the trace on the board, the wire to the breadboard, the breadboard pin, even the metal pin of the IC itself.

This is refereed to in the Arduino reference page:

If the pin isn't connected to anything, digitalRead() can return either HIGH or LOW (and this can change randomly).

If you look at the?:

This also means however, that input pins with nothing connected to them, or with wires connected to them that are not connected to other circuits, will report seemingly random changes in pin state, picking up electrical noise from the environment, or capacitively coupling the state of a nearby pin.

Often it is useful to steer an input pin to a known state if no input is present. This can be done by adding a pullup resistor (to +5V), or a pulldown resistor (resistor to ground) on the input, with 10K being a common value. There are also convenient 20K pullup resistors built into the Atmega chip that can be accessed from software. These built-in pullup resistors are accessed in the following manner.

pinMode(pin, INPUT); // set pin to input digitalWrite(pin, HIGH); // turn on pullup resistors

These weak pull resistors force the input pin state into a known state, and are easily overwritten by stronger input voltages, like a direct connection to ground or +5v.


So tie it high (Via a resistor) to the 5V rail.


Rgds,
Darryl
 

Hi,

"Tie High" means - via a resistor connect this wire to +5V.

Red Wire -----C---- RESISTOR ----------- +5V

Then the junction between the red wire and resistor (Where the "C" is above) is the location you connect to GROUND to set calibration mode.

?

I just checked the code, and it should have the internal pullups active so in theory shouldn't need an external pullup;

pinMode(CAL_BUTTON, INPUT);
digitalWrite(CAL_BUTTON, HIGH); ?

but I would still add a pull-up to be sure as you are having problems.

?

The Red wire you are grounding. Connect this to a resistor (anything above 1K will do) and the other end of the resistor goes to the 5v rail.

Red Wire --------- RESISTOR ----------- +5V

?

The 5v rail can be found on the raduino board. ?

See the circuit attached and note the location/pins of the +5V signal on the connectors, this is what you want to tap into at anyone of those available pins..

?

I dont have one in front of me to show you a physical location.?

Possible locations to pickup +5V;

  • LCD Display connector - Pins 2 or 15
  • Controls connector - Pin 3
  • Arduino Nano - Pin 12
  • The output of the voltage regulator could also be a good option)

Hope that helps

Darryl

?

?

?

On 2017-03-27 04:52 PM, College Professor Simon Thompson wrote:

Hi Darryl
?
Please tell me precisely how I am to do this.
?
What pin do I connect to the 5 v rail? What does “tie it high” mean? Where is the 5 v rail? What resistor (resistance and wattage) should I use??
?
It would be helpful if you could describe the procedure step by step.
On Mar 26, 2017, at 10:39 PM, Darryl Harvey <darryl@...> wrote:

To elaborate on this topic;

Source: ?

What you have is called a?Floating?pin. Digital Input pins are very sensitive to change, and unless positively driven to one state or another (High or Low), will pick up stray capacitance from nearby sources, like breadboards, human fingers, or even the air. Any wire connected to it will act like a little antenna and cause the input state to change. And I mean any wire, the trace on the board, the wire to the breadboard, the breadboard pin, even the metal pin of the IC itself.

This is refereed to in the Arduino reference page:

If the pin isn't connected to anything, digitalRead() can return either HIGH or LOW (and this can change randomly).

If you look at the?:

This also means however, that input pins with nothing connected to them, or with wires connected to them that are not connected to other circuits, will report seemingly random changes in pin state, picking up electrical noise from the environment, or capacitively coupling the state of a nearby pin.

Often it is useful to steer an input pin to a known state if no input is present. This can be done by adding a pullup resistor (to +5V), or a pulldown resistor (resistor to ground) on the input, with 10K being a common value. There are also convenient 20K pullup resistors built into the Atmega chip that can be accessed from software. These built-in pullup resistors are accessed in the following manner.

pinMode(pin, INPUT); // set pin to input digitalWrite(pin, HIGH); // turn on pullup resistors

These weak pull resistors force the input pin state into a known state, and are easily overwritten by stronger input voltages, like a direct connection to ground or +5v.

?

So tie it high (Via a resistor) to the 5V rail.

?

Rgds,
Darryl

?

Capture.PNG
Capture.PNG

 

Okay, one more chance to look dumb. What if A2 which is an analog input and has no voltage by design is actually damaged? And changing the code to A1 or A0 for calibration instead? re-up the sketch working with a new input to the raduino might do the trick.

I had problems at this point too. I used the brown wire and made it blink the blink sketch for me. Not supposed to happen.

I was also getting a calibration mode about half the time I started it in Si5351 calibration mode which is different from raduino calibration mode.

Now look out I am going to be assey a bit....Did you try Johns fixed raduino code at all Professor? It's really good you know.....Maybe you load the sketch and test it. Then you make the changes with the analogue pin inputs according with new plan.

?We see if it works, and I bet I does. If not then you gotta call hfsigs for customer service.

So change your software and pin arrangement or call for india call center support. Otherwise I don't know you, and hey cops I don't know this guy, he keeps on saying that he's a professor and stuff. I dunno bout that dude.

So... that's all I can say now because my Ambien 3D world shifting is kicking in good now.

Try mine before you give up. then go over all your connections again. And bob's your uncle.
Jack Purdum
 

If you want to activate the internal pullups on the Arduino, you would use:

? ?pinMode(CAL_BUTTON, INPUT_PULLUP);

to activate that mode. The options for the second argument in the function call are: INPUT, OUTPUT, and?INPUT_PULLUP. If you use INPUT, it explicitly disables the internal pullups.?

Jack, W8TEE

From: Darryl Harvey <darryl@...>
To: [email protected]
Sent: Monday, March 27, 2017 2:18 AM
Subject: Re: [BITX20] Calibration route

Hi,
"Tie High" means - via a resistor connect this wire to +5V.
Red Wire -----C---- RESISTOR ----------- +5V
Then the junction between the red wire and resistor (Where the "C" is above) is the location you connect to GROUND to set calibration mode.
?
I just checked the code, and it should have the internal pullups active so in theory shouldn't need an external pullup;
pinMode(CAL_BUTTON, INPUT);
digitalWrite(CAL_BUTTON, HIGH);?
but I would still add a pull-up to be sure as you are having problems.
?
The Red wire you are grounding. Connect this to a resistor (anything above 1K will do) and the other end of the resistor goes to the 5v rail.
Red Wire --------- RESISTOR ----------- +5V
?
The 5v rail can be found on the raduino board. ?
See the circuit attached and note the location/pins of the +5V signal on the connectors, this is what you want to tap into at anyone of those available pins..
?
I dont have one in front of me to show you a physical location.?
Possible locations to pickup +5V;
  • LCD Display connector - Pins 2 or 15
  • Controls connector - Pin 3
  • Arduino Nano - Pin 12
  • The output of the voltage regulator could also be a good option)
Hope that helps
Darryl
?
?
?
On 2017-03-27 04:52 PM, College Professor Simon Thompson wrote:
Hi Darryl
?
Please tell me precisely how I am to do this.
?
What pin do I connect to the 5 v rail? What does “tie it high” mean? Where is the 5 v rail? What resistor (resistance and wattage) should I use??
?
It would be helpful if you could describe the procedure step by step.
On Mar 26, 2017, at 10:39 PM, Darryl Harvey <darryl@...> wrote:

To elaborate on this topic;
Source: ?
What you have is called a?Floating?pin. Digital Input pins are very sensitive to change, and unless positively driven to one state or another (High or Low), will pick up stray capacitance from nearby sources, like breadboards, human fingers, or even the air. Any wire connected to it will act like a little antenna and cause the input state to change. And I mean any wire, the trace on the board, the wire to the breadboard, the breadboard pin, even the metal pin of the IC itself.
This is refereed to in the Arduino reference page:
If the pin isn't connected to anything, digitalRead() can return either HIGH or LOW (and this can change randomly).
If you look at the?:
This also means however, that input pins with nothing connected to them, or with wires connected to them that are not connected to other circuits, will report seemingly random changes in pin state, picking up electrical noise from the environment, or capacitively coupling the state of a nearby pin.
Often it is useful to steer an input pin to a known state if no input is present. This can be done by adding a pullup resistor (to +5V), or a pulldown resistor (resistor to ground) on the input, with 10K being a common value. There are also convenient 20K pullup resistors built into the Atmega chip that can be accessed from software. These built-in pullup resistors are accessed in the following manner.
pinMode(pin, INPUT); // set pin to input digitalWrite(pin, HIGH); // turn on pullup resistors
These weak pull resistors force the input pin state into a known state, and are easily overwritten by stronger input voltages, like a direct connection to ground or +5v.
?
So tie it high (Via a resistor) to the 5V rail.
?
Rgds,
Darryl
?
 

Unfortunately the Arduino Digital Pin Tutorial is somewhat misleading ?in that it highlights the Pullup setup for older Arduino Versions in a box and only describes in the text how to do it the new way.

The correct way to enable internal pullup, as Jack has written is:?

pinMode(CAL_BUTTON, INPUT_PULLUP);

but it has to be followed by a

digitalWrite(CAL_BUTTON,HIGH);

to actually connect the internal?pullup resistor to 5V.
 

It's not all that complicated to make sure you are programming the correct code into the Raduio.. ?I believe good working code similar to what got shipped with the kit can be found at ? ? and described in the thread ?/g/BITX20/topic/4479273? ? Make a minor change to the sketch, in this case perhaps the calibration message:

? ? ?old: ? ?printLine1("Calibrating: Set");

? new:?printLine1("Calibrate: Set");


Compile and upload to the Raduino. ?If you see the new message, then you know the program is getting successfully loaded.


Weird that the Arduino's have occasional reports here of corrupted flash, and need to be reprogrammed. ?On most microcontrollers I've dealt with in the past this never comes up. ? Since Simon is not seeing a high of 5v ?on the calibrate wire, perhaps that wire got shorted to something and it blew the io cell. ?If so, and if adding a 1k pullup resistor from the calibrate wire to 5v does not help, I would try moving the calibrate pin in the Raduino sketch:

? ? old: ?#define CAL_BUTTON (A2)

? ? new: ?#define CAL_BUTTON (A0)

and use the black wire on the 8'th pin of the connector for calibrate instead of the red wire on the 6'th pin.


Jerry, KE7ER

#define CAL_BUTTON (A2)
#define CAL_BUTTON (A2)



#define CAL_BUTTON (A2)
#define CAL_BUTTON (A2)




Essentially, I think when you disconnected everything and reloaded, You either did not reload,
or you reloaded the same hex file as before.

?
 

开云体育

For hardware designed around a pin having a pullup with a specific purpose, an additional external pullup is preferred to counter programming error or other issue.? One less chance for a typo to create havoc.


On 3/27/2017 10:41 AM, DJ2AG wrote:

Unfortunately the Arduino Digital Pin Tutorial is somewhat misleading ?in that it highlights the Pullup setup for older Arduino Versions in a box and only describes in the text how to do it the new way.

The correct way to enable internal pullup, as Jack has written is:?

pinMode(CAL_BUTTON, INPUT_PULLUP);

but it has to be followed by a

digitalWrite(CAL_BUTTON,HIGH);

to actually connect the internal?pullup resistor to 5V.

1 - 20 of 31