I am trying to transmit signals from the smol ARTIC R2. I do not have GNSS components so I modified the example SparkFun code to exclude the GNSS functionality and then ran it. The program uploads successfully and the data is written, but there are errors that appear in the Serial monitor that prevent anything from being transmit. When I try to transmit one package and go idle through the sendMCUinstruction function, I first get a busy flag, then an MCU command overflow flag, and then a DSP2MCU_INT2 flag which causes the program to terminate. I am unable to find what command or section causes the program to overflow initially. Any thoughts and suggestions would be greatly appreciated.
Hi,
Have you tested one of the simpler examples - like Example3 (Satellite Detection)? Does that work OK?
Can you also please copy and paste the error messages you are seeing. Or attach a screenshot.
Thank you,
Paul
Also, with the smôl boards, it is very important that you define the GPIO and Chip Select pins carefully. Please see this post for more details. Maybe you are having the same issue?
viewtopic.php?p=240268#p240268
Best,
Paul
When I run the satellite detection code, the serial monitor displays that the firmware is receiving but does not actually detect a satellite. This may be only a location and timing issue.
I have attached the error message that appears in my serial monitor for the transmission code.
OK - thank you.
I think this is a coding error. Please try Example4 (ARGOS4 VLD) - unmodified. Does that work OK?
Please look through your code and make sure you are following the same steps.
Best,
Paul
PaulZC:
Also, with the smôl boards, it is very important that you define the GPIO and Chip Select pins carefully. Please see this post for more details. Maybe you are having the same issue?viewtopic.php?p=240268#p240268
Best,
Paul
I am using only the smol ESP32 and ARTIC boards. When I changed the Artic power pin number from 27 to 26, the program now fails and freezes on the first attempt. Prior to this, I am getting the same error messages as before. I have attached the code I am running below. What changes should I make now?
ex1_2.cpp (13 KB)
Hi,
I am sorry. I do not have time to look through your code in detail right now. It will try to do it, but it will not be until Monday.
Meanwhile, please try smôl Example4 (ARGOS4 VLD) - unmodified. Does that run correctly?
Best,
Paul
PaulZC:
OK - thank you.I think this is a coding error. Please try Example4 (ARGOS4 VLD) - unmodified. Does that work OK?
Please look through your code and make sure you are following the same steps.
Best,
Paul
When I run example 4 unmodified, the Serial monitor displays the message as being transmitted at the necessary intervals. However, the goniometer that I have set to receive signals from my specific smol board does not receive anything.
Ok. Thank you.
I am not familiar with the goniometer. Can it receive ARGOS4 VLD?
It may be possible for you to adapt the main examples Example17 (ARGOS2) and Example18 (ARGOS3). If you are careful, you should be able to cut and paste the frequency and payload code from those examples into the smôl Example4.
I hope this helps,
Paul
I have taken a very quick look at your code and I can see one major problem with it.
You have removed the “state machine” switch/case statement in the main loop. You are not using loop_step at all.
You are telling the ARTIC to transmit one packet every time you go around the loop (myARTIC.sendMCUinstruction(INST_TRANSMIT_ONE_PACKAGE_AND_GO_IDLE)).
You are only checking firmware status and instruction progress one time, each time you go around the loop.
I am sorry, but that is completely wrong.
You need to keep checking the status and instruction progress, and wait for the transmit to complete (or fail).
You are immediately trying to send a new package, while the first one is still awaiting transmission. That is causing the error.
Please look at the code examples again. They are very clear. The state machine (loop_step switch/case) controls the flow of the code. It is important that you do it the same way.
Best wishes,
Paul
Hi @rparanji,
We learned recently that some ARTIC R2 boards had been incorrectly programmed with the wrong Platform ID. Each board has two IDs: a decimal one which you use to access your data on ArgosWeb; and a hexadecimal one which is embedded in each satellite uplink message. These boards had been incorrectly programmed with the decimal ID instead of the hexadecimal one. You can tell if your board is affected by calling readPlatformID(). If the true hexadecimal ID is returned, all is well. If the value is the decimal ID - expressed in hexadecimal - then your board requires reprogramming as your messages will not be delivered. Please return your board ( https://www.sparkfun.com/returns ). We will reprogram it and return it to you quickly. If your project is time-critical, please contact us again here and we will provide a software work-around. We apologise for the error and the inconvenience.
Best wishes,
Paul