SEN0386 not changing frequency on Arduino Uno R4 Wifi

Support Product Questions
21

Hey @Kitten23 , welcome to the forums!

Hopefully, the original poster can jump in here with a resolution.

My best guess would be to try and change the frequency using the following code:

DFRobot_WT61PC sensor(&FPSerial);

unsigned long lastTime = 0;  // Store the last time we printed the frequency
unsigned long count = 0;     // Store the number of times data was received in the last second

void setup()
{
  //Use Serial as debugging serial port 
  Serial.begin(115200);

  FPSerial.begin(9600);


  sensor.modifyFrequency(DFRobot_WT61PC::FREQUENCY_100HZ);
}

The important change in that is to this line:

sensor.modifyFrequency(DFRobot_WT61PC::FREQUENCY_100HZ);

The acceptable frequency values are:

  • FREQUENCY_0_1HZ
  • FREQUENCY_0_5HZ
  • FREQUENCY_1HZ
  • FREQUENCY_2HZ
  • FREQUENCY_5HZ
  • FREQUENCY_10HZ
  • FREQUENCY_20HZ
  • FREQUENCY_50HZ
  • FREQUENCY_100HZ
  • FREQUENCY_125HZ
  • FREQUENCY_200HZ

Let us know if this helps!

22

Hi !

Thank you for your fast answer.

Unfortunately, your code doesn’t work and the error message is the following :slight_smile:

In file included from C:\Users\Documents\Arduino\DFRobot SEN0386\sketch_fev05a\sketch_fev05a_test\sketch_fev05a_test.ino:1:0:
C:\Users\Documents\Arduino\DFRobot SEN0386\sketch_fev05a\sketch_fev05a_test\sketch_fev05a_test.ino: In function ‘void setup()’:
c:\Users\Documents\Arduino\libraries\DFRobot_WT61PC/DFRobot_WT61PC.h:36:28: error: expected unqualified-id before numeric constant
#define FREQUENCY_100HZ 0X09
^
C:\Users\Documents\Arduino\DFRobot SEN0386\sketch_fev05a\sketch_fev05a_test\sketch_fev05a_test.ino:44:42: note: in expansion of macro ‘FREQUENCY_100HZ’
sensor.modifyFrequency(DFRobot_WT61PC::FREQUENCY_100HZ);
^~~~~~~~~~~~~~~
exit status 1

Compilation error: exit status 1

This sensor will make me cry :’(

1 Like
24

Hey there, @Kitten23,

The FREQUENCY_100HZ is just a macro defining a text substitution as indicated by the line:

#define FREQUENCY_100HZ 0X09

When it’s crashing out on

sensor.modifyFrequency(DFRobot_WT61PC::FREQUENCY_100HZ);

It’s most likely because it’s looking for the value DFRobot_WT61PC::0x09, which is not defined as anything.

Could you instead try the above code with just:

sensor.modifyFrequency(FREQUENCY_100HZ)

And let us know what happens.

25

Hi, I suspect I have the same problem. I have the DFRobot sen0386. I bought it with the assumption that it would give me an “angle” reading and not just a rotation rate that I’d have to integrate/do a kalmen filter or other mathemagics on. It does indeed seem to give a good angle reading but only at a rate of 10Hz.

Using the stock example code and changing FREQUENCY_10HZ ro FREQUENCY_100HZ) does not seem to change the “loop frequency”.

I have confirmed that the code causing the “delay” in the loop is the example code:

if (sensor.available()) {

If you time this piece of code it takes almost exactly 100ms. If you count, say, the number of times this is executed in one second, you get the same result.

AI answers on the web say to remove Serial.prints, delays, etc. That does nothing.

AI also recommends reading the registers directly to see if the command to change the frequency is actually taking place. I’m too much of a newb to know what it’s talking about to do that. AI suggestion:

2. How to Read the Register (Command)

To verify the update, you must send a “Read Register” command to the sensor and parse the response.

Command to Read Register 0x03:
0xFF, 0xAA, 0x27, 0x03, 0x00

  • 0xFF, 0xAA: Header

  • 0x27: Read Command

  • 0x03: Register Address

  • 0x00: Reserved/Checksum placeholder

I have briefly and inexpertly examined the DFRobot_WT61PC library files and don’t see any “delay (100)” or other things like that, but again, I’m just a newb looking at somewhat-greek-to-me code.

This is for a balancing type project and I think it needs way better than 10Hz feedback. I have tried another IMU, BMI270, which seems to probably run fast enough to work. But then I need to do a bunch of math and kalmen filters and probably other stuff to get a realistic and reliable “angle” value, which I have not been successful with yet. Probably due to my newbness.

Would be a super big help if I could just read an angle and be done with it.

Help?

1 Like
26

@Johnsinski315332 what you’re seeing looks consistent with the sensor or library only delivering fresh data about every 100 ms, so the practical update rate ends up around 10 Hz even when the frequency setting is changed.

The key part of your post is this:

if (sensor.available()) {

If that call is taking roughly 100 ms each time, then your loop rate is being gated there, not by Serial.print() or the rest of your sketch. So your diagnosis makes sense.

One thing worth noting from the Serial 6-Axis Accelerometer for Arduino specs is that this module is listed as fixed at 9600 bps while also claiming 1–200 Hz output. That combination is a bit odd, and it could explain why people keep landing around 10–11 Hz in practice if the library is waiting on complete serial packets before returning true from available().

So at this point I’d treat it as one of two likely cases:

  • the frequency change command isn’t being accepted by the sensor, or
  • the sensor/library combination is effectively limited to about 10 Hz in normal use, despite the advertised selectable rate

If you can, post:

  • your Arduino model,
  • the exact library version you installed,
  • and whether FREQUENCY_1HZ also still gives ~10 Hz.

That last test is especially useful — if every setting still gives ~10 Hz, it points pretty strongly to the command not taking effect at all, rather than just a throughput bottleneck.

1 Like