arduino-dw1000
arduino-dw1000 copied to clipboard
thotro
DWM1000 error in CLKPLL_LL_BIT
Hi:
I have been trying to make this code work on an Arduino Mini PRO 3.3 8Mhz like the one in the testbed ( receiver) and an arduino Mega 2560 ( transmitter). The Tx works Ok, or at least i think so, but the RX doesn't receive anything. If i artificially make the interrupt go i see the package is corrupted in the receive buffer and the CLKPLL_LL_BIT is set, although this doesn't generate the interruption by itself. Do you have any insight on this error? Is there an specific reason why the CLKPLL_LL_BIT is checked in your code.
Best regards.
Hi there, from the user manual on CLKPLL_LL: "Clock PLL Losing Lock. This event status bit is set to indicate that the system’s digital clock PLL is having locking issues. This should not happen in healthy devices operating in their normal range. Its occurrence may indicate a bad configuration, a faulty part or a problem in the power or clock inputs to the device."
I learned from my early breadboard, protoboard tests that everytime I received corrupted packages, at the same time as I observed a clock-losing-lock event. In most cases it was a loose wire or a low-level misconfiguration (which I hope it is not! :-)).
CLKPLL_LL is never present in the interrupt mask, so yes, this cannot be the source of interruption. Still interrupting artificially (while one device is constantly sending packets, right?) will likely never give you good packets - I guess. So for now, I'm sorry, but don't have a single solution to your problem.
Maybe you have some additional information on your setup and device configurations? Let me know if there's anything else I can help with.
Cheers, Thomas
Hi, thanks for your answer. I am using the same configuration that it is described in the github repository, with the adapter board and a protoboard with an arduino mini pro. What do you mean with low-level misconfiguration? Tuning Failure? OTP or LDE failure?
Best regards. José
2015-09-17 4:39 GMT-03:00 Thomas Trojer [email protected]:
Hi there, from the user manual on CLKPLL_LL: "Clock PLL Losing Lock. This event status bit is set to indicate that the system’s digital clock PLL is having locking issues. This should not happen in healthy devices operating in their normal range. Its occurrence may indicate a bad configuration, a faulty part or a problem in the power or clock inputs to the device."
I learned from my early breadboard, protoboard tests that everytime I received corrupted packages, at the same time as I observed a clock-losing-lock event. In most cases it was a loose wire or a low-level misconfiguration (which I hope it is not! :-)).
CLKPLL_LL is never present in the interrupt mask, so yes, this cannot be the source of interruption. Still interrupting artificially (while one device is constantly sending packets, right?) will likely never give you good packets - I guess. So for now, I'm sorry, but don't have a single solution to your problem.
Maybe you have some additional information on your setup and device configurations? Let me know if there's anything else I can help with.
Cheers, Thomas
— Reply to this email directly or view it on GitHub https://github.com/thotro/arduino-dw1000/issues/42#issuecomment-140993383 .
Hi José,
yes, that's basically what I meant - maybe not an LDE error, but a tuning or OTP problem. Did you try with the default configuration (Channel 5, 16 MHz, ..., e.g. by not setting any mode explicitly) or even with other ones as well?
Which Arduino sketches do you use for testing? BasicSender/-Receiver?
I am using Basic sender/receiver, with default settings. When i change setings the chips behave differently, it triggers receive interruptions when i intentionally configure different baud rates between receiver and sender ( same channel and PRF, different baud rate and preamble legth) . i haven tested what happen when i do not pass any settings to the chip, but it will be my next test. Thanks.
2015-09-17 9:51 GMT-03:00 Thomas Trojer [email protected]:
Hi José,
yes, that's basically what I meant - maybe not an LDE error, but a tuning or OTP problem. Did you try with the default configuration (Channel 5, 16 MHz, ..., e.g. by not setting any mode explicitly) or even with other ones as well?
Which Arduino sketches do you use for testing? BasicSender/-Receiver?
— Reply to this email directly or view it on GitHub https://github.com/thotro/arduino-dw1000/issues/42#issuecomment-141071653 .
I'm having a similar problem with the receiver using the adapters with the same setup. Using leonardo for both sender and receiver. Receiving corrupted data every 1-2 minutes.
Output from receiver: ** Error receiving a message Error data is ... Helll� �y�y>i�P.�i�{� **
Is this a hw issue? I might have weak connections from soldering...not sure though. Also, I'm assuming the pull down resistor on the irq pin is 330 Ohm? (orange orange brown).
I have the same problem. I have used Arduino Uno to BasicSender and ArduinoEthernet to BasicReceive. I have modified the library to print the specific bit. In praticular: *_when i send i print TXFRS_BIT and it's equal to 1 (it's ok, it means send done). *_when i receive i print LDEERR, RXFCE, RXPHE, RXRFSL and all are equal to 0 (no error) but the CLKPLL_LL is always equal to one.
Do you have any insight on this error?
Do you get to solve your problem? I have the same issue it's seems that the transmitter it's working well, but i can't recieve any data in the receiver module, i'm using Two arduino promini 16MHz @ 5V with level shifter.
+1 on this issue. I have the exact same problem than @nevercy89, @Joshua-Thompson, @maxicastle and @jesp007. My configuration is actually using a Teensy 3.2, it sends data without any problem, the BasicConnectivityTest is also working good, but I always receive corrupted data with BasicSender/BasicReceiver sketchs due to a CLKPLL_LL_BIT error.
Do you guys have any updates on this subject ?
Hey guys, I could send and receive .. my problem is the Tx cant receive back again from Rx !! Status Register is always wrong from Tx side !!
Any Suggestion ? Thanks in advance
