What is "Programmer: AVRISP MkII"?

Development Tools IDE 1.x
1

I am working on a project which involved two UNOs communicating via NRF24L01 PCBs with one of them controlled by an HC-SR04 ultrasonic sensor. I am having problems getting existing, proven, code to run. I originally suspected hardware problems because I have had to transport the kit several times. However, full hardware replacement has not solved anything.

I was using Arduino 1.6.10. I have just done a clean uninstall of that and replaced it with Arduino 1.6.12. This includes RF24 (TMRh20) v1.1.7, and Firmata v2.5.4.

I just noticed Programmer: AVRISP MkII. What is that, and is that the correct selection?

2

That setting is only used for Tools > Burn Bootloader and Sketch > Upload Using Programmer. If you're not using either of those then the Programmer setting makes no difference.

3

Thanks pert.

Offhand, do you have any suggestion as to how proven code could just stop working? Literally, code that was working in the morning has not worked since the evening. I am at my wits end and the class project depends on this.

4

Please explain what "stop working" means.

5

I described the problem in the original post. On Wednesday morning I had working code. I took the hardware to school for a demonstration and when I got it home that unchanged code did not work. Nothing I have thought of has got it working again: not hardware replacement, not IDE replacement, not trying legacy code that worked a week ago and has lain untouched.

I began to suspect that some "upgrade" or other had corrupted the system on my PC so I changed from Arduino 1.6.10 to 1.6.12 etc.

readRangeHC-SR04 (which does not require radio telecommunication) works fine.
Console and Trolley (which operate on Rx/Tx) run but do not communicate.

I cannot figure out why what worked in the morning has not worked since.

readRangeHC-SR04.ino (1.87 KB)

Trolley.ino (14.2 KB)

Console.ino (8.13 KB)

6

Write a simplified sketch that just sends/receives "hello" once a second. This will tell you if your radios are working.

Did you do an update of the Arduino AVR Boards version between the working and non-working state? If you have them enabled the Arduino IDE will pop up an updatable boards notification when there is a new version available of any of your installed hardware cores. There shouldn't be any difference between the version included with 1.6.10 and the latest version that would cause your issue but it's possible you were using an older version previously and there have been some significant changes in recent versions of Arduino AVR Boards that can cause issues in rare cases.

I haven't looked very carefully at your code but one thing I noticed is that it seems like you are unnecessarily using arrays for your commands. If you're only using a single character of the array then why use an array at all instead of just char? It probably works as you have it but that just adds unnecessary complexity and possibly increases memory usage. It's best to keep things as simple as possible to reduce the potential failure points but it's also not a good idea to make unnecessary changes to your code until you've gotten it back to a working state, otherwise you can't test the changes.

7

pert:
Did you do an update of the Arduino AVR Boards version between the working and non-working state? If you have them enabled the Arduino IDE will pop up an updatable boards notification when there is a new version available of any of your installed hardware cores. There shouldn't be any difference between the version included with 1.6.10 and the latest version that would cause your issue but it's possible you were using an older version previously and there have been some significant changes in recent versions of Arduino AVR Boards that can cause issues in rare cases.

Thanks you pert. You have obviously given this a lot of thought.

Yes. There has been a recent upgrade of Arduino AVR Boards. Yes. The horrible thought of some difference has crossed my mind. No. I have no idea of what to do about it.

Never having been involved in programming in this context before, I am pushing the boundaries of my capability as it is. However clumsy the code I wrote (and Yes I am equally puzzled about the use of const char start[] = {'S'}; instead of const char start = 'S';, but that is the way the base code from which I developed was written). however clumsy - it worked. A group of Mechanical Engineering students were depending on it working to drive the machine they have built, and now it does not work. It did work - I set LEDs on all the inputs and outputs, and I filled the code with debug statements to show me that it was achieving its purpose - and now it does not work.

There is little point in my wailing, "What am I to do?" because I would not know where to begin. All I can hope is that you, and others in this Forum far better equipped than I, will help me with a solution. Perhaps whoever wrote the aforementioned AVR Boards Update can assist.

Thanks

8

vagulus:
There has been a recent upgrade of Arduino AVR Boards.

Do you know which one you were using? You could try Arduino AVR Boards 1.6.11. That was the last one before the compiler update and switch to using LTO. You can install it via Tools > Boards Manager and you can go back to using the current version the same way.

vagulus:
All I can hope is that you, and others in this Forum far better equipped than I, will help me with a solution.

Do what I said:

pert:
Write a simplified sketch that just sends/receives "hello" once a second. This will tell you if your radios are working.

You need to narrow down the cause of the problem. If you can send a message using the radios with a simplified sketch then you know the radios are working, you know the sensor is working, so that would mean your hardware is working.

9

Hi pert

Firstly, I am not ignoring your suggestion to ... write a simplified sketch ...", it's just that I wouldn't know how. The only way I have a RF communication sketch is to modify the originals robin2 wrote - and at present they do not communicate. Catch 22!

I changed the AVR Board back to 1.6.11 and the compiler threw a paddy over pointer problems about addressing the char[] message data type. I have always had problems with pointer addressing in the C-style languages so I retreated and went to Boards v. 1.6.13. That resulted in no pointer problems but still no link, so I thought, "Well, why not?" and installed v. 1.6.12. That gave no pointer problems and no link, but the compiler posted an error message, "An error occurred while uploading the sketch". Despite the message the sketches attempted to run! Whatever is going on with these versions of AVR Boards is beyond me, but again I retreated and re-installed v. 1.6.13.

I had noticed that, when starting, Trolley stalled somewhere in loop(), so I started adding debug messages until I found the location of the stall. These show in the attached version. Uploading this version of Trolley (without Console even being powered up) results in the output:

Trolley Starting
In getData - newData = 0
Data read by Trolley.getData ><
In showData - newData = 1
Trolley.showData - Data received
In send() - newData = 1
In send() - sending message
In send() - listening stopped

This tells me two things:

  1. getData() reads something even when being protected by a radio.available check.
  2. Execution stalls at Trolley(192) on a radio.write command. Well, that command is supposed to block for 60-70 ms, but not forever. However: with execution stalled where it is, Trolley is not listening. That explains why, when Console starts, Trolley does not respond.

The questions now are: why getData() gets data when none exists, and why execution stalls on the radio.write.

Trolley.ino (14.2 KB)

10

Hi,
nRF24L01 intermittent problems (Work today, fail tomorrow) are not uncommon. This is usually related to power and bypassing which nRF24L01 modules are very sensitive to. I suspect the problem is not software at all.

See http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo and the "Problems" lines.

I had hundreds of nRF24L01 modules in kits I make for a large school system 2 years ago. Many students had intermittent problems. Last year all modules were supplied with the "Base Modules" shown on that page and the reliability was high. Phew... Those little modules have a good 3.3V regulator and good bypass capacitors.

The nRF24L01 modules were designed to plug into a pc board with good low-inductance bypassing and solid 3.3V power. Hanging them on jumper wires is NOT GOOD.

Let us know what you learn!

11

vagulus:
Firstly, I am not ignoring your suggestion to ... write a simplified sketch ...", it's just that I wouldn't know how. The only way I have a RF communication sketch is to modify the originals robin2 wrote - and at present they do not communicate. Catch 22!

That's the wrong approach to a project. You need to understand what the code you're using actually does. That's why you need to start with a simplified test sketch for each component of your project, understand what that code does, and get each one working before combining them together. Copying and pasting a bunch of code together that you don't understand will only lead to a bunch of confusion in the end. Arduino is meant to make learning easier, not to allow you to avoid learning altogether. If you look at File > Examples > RF24 you'll see a lot of example sketches using the RF24 library. I'm not familiar with that library but you should be able to find a simplified test sketch in those examples. Then go through it line by line until you understand it.

I agree with terryking228 that there's a good chance this is a hardware issue related to your radios but it's very useful to have a known-good, dead-simple test sketch to fall back on when you encounter issues. Even though the Blink sketch is the most basic, first sketch for most Arduino users, I still end up uploading it to my boards surprisingly often as a sanity check. I'm saying you need the RF24 equivalent of Blink, so simple that you know there's no chance of a bug in the sketch.

vagulus:
the compiler threw a paddy over pointer problems about addressing the char[] message data type. I have always had problems with pointer addressing in the C-style languages so I retreated and went to Boards v. 1.6.13.

When Arduino upgraded the compiler in Arduino AVR Boards 1.6.12 they decided to add a -fpermissive compiler flag because some bad code that was previously allowed now would cause an error with the new compiler version without that flag. Unfortunately this also allows bad code that wouldn't compile with Arduino AVR Boards 1.6.11 or earlier to compile with Arduino AVR Boards 1.6.12 or later. This may be the case with your code. I suggest that you do set File > Preferences > Compiler Warnings: All, compile your sketches, then closely examine all the output shown in the black console window at the bottom of the Arduino IDE window. You should always have warnings set to All, pay attention to them, and fix every warning unless you're absolutely sure that it's not a problem. Unfortunately some library/core authors are sloppy and their code causes some warnings(or, very rarely, there is a good reason not to fix a warning) you may need to ignore these warnings but you should never do so for your own code. The core/library warnings will only be shown on the first compile, after that only warnings for the sketch and any other files that have been altered will be shown.

Saying "the compiler threw a paddy over pointer problems about addressing the char[] message data type." is much less useful to people trying to help you than just copying the actual compiler output. Always use code tags for compiler output, otherwise the forum software might interpret some of the output as markup code, thus not rendering it correctly.

12

Terry

Do you have a part number/model number/some number by which I might be able to find the Base Module at our local suppliers. I have just been browsing their websites and haven't had any luck using the term Base Module. Some more technical ID would be great. Thanks

Also, looking at your pictures showing connection of Base Module to RoboRed, you have an extra wire (going to IRQ). Do I need that when using a UNO?

pert

I take on board what you are saying about getting to understand the subject, but please remember I got dropped into this at the deep end from a great height. I tried to concentrate on results instead of understanding - and it was working until I discovered that, as Terry put it, nRF24L01 intermittent problems (Work today, fail tomorrow) are not uncommon. :fearful:

If you look at File > Examples > RF24 you'll see a lot of example sketches using the RF24 library. I'm not familiar with that library but you should be able to find a simplified test sketch in those examples.

I'm saying you need the RF24 equivalent of Blink, so simple that you know there's no chance of a bug in the sketch.

I'll get on to that a.s.a.p. which probably means tomorrow afternoon (it's 1625 here at the moment).

13

I am starting with Getting Started (from File --> Examples --> RF24 in the IDE and following the steps in Terry's page. A couple of hours working though this again and again getting things right until I am sure the setup is as it should be. I have set these lines in setup() in both instances of the sketch

  radio.setPALevel(RF24_PA_MAX);

  radio.setDataRate( RF24_250KBPS );
  radio.setChannel( 108 );

One has radioNumber = 1, the other 0

Without radioNumber = 0 being powered up, I get this output from starting up radioNumber = 1

RF24/examples/GettingStarted
*** PRESS 'T' to begin transmitting to the other node
Sent response 0
Sent response 269484048

I powerup and start radioNumber = 0 and get

RF24/examples/GettingStarted
*** PRESS 'T' to begin transmitting to the other node

I go to radioNumber = 1 and enter 'T' and get

RF24/examples/GettingStarted
*** PRESS 'T' to begin transmitting to the other node
Sent response 0
Sent response 269484048
*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK
Now sending
Failed, response timed out.
Now sending
Failed, response timed out.
Now sending
failed
Sent 959690664, Got response 7340032, Round-trip delay 10248 microseconds
Now sending
Failed, response timed out.
Now sending
failed
Sent 961909904, Got response 4097, Round-trip delay 7912 microseconds
Now sending
Failed, response timed out.
Now sending
failed
Sent 964127168, Got response 0, Round-trip delay 8456 microseconds
Now sending

Nothing changes with radioNumber = 0.

If I repeat the startup process but this time enter 'T' in radioNumber = 0 it prints out

RF24/examples/GettingStarted
*** PRESS 'T' to begin transmitting to the other node
*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK
Now sending
failed
Failed, response timed out.
Now sending
failed
Failed, response timed out.
Now sending
failed
Failed, response timed out.
Now sending
failed
Failed, response timed out.
Now sending
failed
Failed, response timed out.

and nothing changes in radioNumber = 1.

I haven't been able to get the Base Module Terry talks about but I have added a Red Wings power supply to each unit.

Does anyone have any idea of what else can be stopping the cross-communication?