Arduino Lightsaber for/with LED string blade

PedroRS: Hi,

Regarding metadata, I read about it from the developer of this library: https://github.com/jonnieZG/DFPlayerMini. He mention about it in the readme: "The DFPlayerMini supports both WAV and MP3 formats. When using WAV files, you should make sure to remove any metadata from the WAV file, since the player will interpret it as noise." Attached an example screenshot of the metadata included in volume.wav. After remove this data and save save the file without them "my" dfplayer is not reproducing noise at the end of the track.

By other side, I confirmed the IC mounted in my board and it's not one of the references you mentioned. I added a picture. It's like "JC AA1746CJ1Uxxxxx"Any number is matching... and I cannot find any reference in google about it... :-)

Maybe the firmware version of my boards are different or just olders... I will investigate about it because according datasheet there is a query for software version.

I will post If I have updates.

This certainly does not look like a genuine DFPlayer... where did you get it? The DFPlayer chips are from a Chineese company called YX and the 2 products mentioned are the only ones mounted on genuine DFPlayer parts.

I bought them from Aliexpress. But there are a lot of sellers offering this product. Exactly this one in my case: https://es.aliexpress.com/item/5Pcs-DFPlayer-Mini-MP3-Player-Module-For-Arduino/32750446150.html?spm=a2g0s.9042311.0.0.3BHe06 Of course the chip I received is not the one you can see in the pictures. They are showing DFRobot module, same as the original com DFRobot.com

I will order form another seller or the original ones. In Aliexpress I could see customer pictures of the product and the mounted IC are the YX one.

I ordered some DFPlayers to play with as well..

stand alone used with an Arduino, not a completed DIYino board to be clear.

They are legit boards/chips..

I have 1 hardware question and some software questions if anyone has dealt with this, I'd appreciate some feedback.

I currently get a loud POP from the speaker conected to the DFPlayer when the project is powered on/off..

Audio playback once powered up is fine.

Has anyone had this issue? And what was your fix? I read about a MOD to the DFPlayer board itself.. (but was hoping for alternate solutions?)

Secondly.. (I'm currently using the DFRobot lib, but will use another if meets my needs and has documentation about the functions/how to use them..etc)..

How are people detecting the 'end' of the file playback? (ie: playback completion?)

I am currently attempting this as so:

I only need to know when track '2' is done playing (which is only set to be played once)... so I can automatically trigger another file to play an in infinite loop..

currentTrack is var to hold the currentTrack playing doCompletion check is a var so the 'check' only happens one time in my loop.

if(currentTrack == 2 && doCompletionCheck == true){
    if(myDFPlayer.available()) {
       if(isFinished(myDFPlayer.readType(), myDFPlayer.read()) == 1){            
        //Serial.println(F(">>> PLAYBACK COMPLETE <<<"));        
        currentTrack = 3; 
        doCompletionCheck = false;    
        myDFPlayer.loop(3);                          
      }              
    }
}

I have tried readState() readType()...

and combinations of both..

I found the serial output seems correct, but the audio gets 'janky'...

project summary: press button, triggers 001.wav to play (once) if button is still being pressed and 001.wav is complete,..trigger 002.wav to play immediately, and loop forever (until button is released) when button released, play 003.wav file (once)..

I have/am experiencing the same issue as PedroRS is.... Is there a proper procedure/order when playing a file one time and playing a looping file.. and then going to another file to play it once?

sometimes the 001.wav doesnt trigger after running the looped file for a while, sometimes the 003.wav file doesnt play.. or the 001.wav doesnt play when the button is pressed again.

I -feel- like there is supposed to a proper way to 'stop' the files from playing before calling a new one to play? (but sometimes it DOES work)..

I have no delays in my sketch, its a FSM type of approach...

The above is even more prevalent when I added in some Neopixels.. (more audio playback issues)

Any ideas? or suggestions?

Is there any specific documentation about the other DFPlayer classes out there? DIYino or neskweek variant? (I'm looking for some documentation of the public methods, and what they do/examples of usage)..

Maybe these have built in 'watch dogs' for when I file completes playback?

Update question: Has anyone else ran into issues while using NeoPixels, and serial comm. with the DFPlayer? The NeoPixel lib (form my understanding) disables interrupts during its updating of the led strip... disabling of interrupts causes issues with serial communication (which is needed for communicating to the DFPlayer).. what has everyone been doing to address this issue? Different approach? Different libraries? (although I'm not sure if you can work around the timing requirements of the Neopixels)..

Thanks!

@Protonerd

Yikes! Sorry I didnt realize until now this was a gallery post!! (sorry).. I just saw others discussing their component issues..etc..etc.. and posted. I can move it if you like.

Good news for all those who want to have a known-good module with a proven architecture, and that for a very friendly price:

I proudly and happily announce the newest member of my Arduino compatible family of boards, the

DIYino Stardust V3 (NEW!!!)

|500x232

More info can be found here:

Link to Stardust V3 thread

PedroRS: Hi guys

I'm building a homebrew (right now as prototype using Aurduino UNO) + neopixel strip version. Final target is to use 18650 battery but currently I'm using laboratory power supply fixed to 5V.

After configuring the OS and burn the code mainly all seems working fine. Congratulations Protonerd !!!!! :stuck_out_tongue_closed_eyes:

But operating it a little bit I found one audio issue. SOME of the sounds keep in infinite loop after playing them. For example the saber ignition off or some config menu voices. I can solve the issue provoking another audio execution or rebooting.

Are someone facing a similar problem?

I could notice some uP reboots navigating through config menu always including some strange noise in loop as well... but I'm not sure if it's related or not.

I'm using the serial resistor in DFPlayer RX line to adapt arduino tx 5V.

Thanks in advance !!! Pedro.-

Replying myself.... and just to help somebody facing same issue.

I confirmed the route cause of problem with DFPlayers mounting non XY devices (they have a lot of incorrect behaviors). After replace in my modules the IC with an XY all is working as expected (audio loop stops, metadata in wav files are not provoking noises, and no more hung ups while navigating the config menu). Seems like a firmwares issue or similar...

Regards!

Great, so the clear message is: check that you have a genuine DFPlayer wih an YX chipset. Or even better, get a DIYino board, then you do not have any risk, all the components are genuine, and sure to work :)

Taking into account all extra parts I bought to resolve the problem it don’t seems a crazy option, sure… :smiley:

PedroRS:
Taking into account all extra parts I bought to resolve the problem it don’t seems a crazy option, sure… :smiley:

That is one reason among a few I decided to make the DIYino boards. At the price point the V3 is currently sold, it’s nothing short of a bargain.

I made quick statistics, 95% of the problem support I give to people over on GitHub how to use FX-SaberOS are related to homebrew solutions. No complaint so far with any DIYino boards other than folks not reading the manual.

PedroRS: I created inside DFPlayer_LSOS library a function to call this serial command (0x11 0x00) and executing it like this, the issue is solved...:

Hey Pedro!

I'm having the same issue, after i bought a DFplayer from Ali Express. I don't have the requisite knowledge to modify the library correctly.

I've tried adding the following code to the DFPlayer.h in the DFPlayer_LSOS library:

inline void disableAllLoops() {
        setSendBuffer(0x11,0x00);
    }

I then added your amendment to the FX-SaberOS script.

Would it be possible for you to provide more details so i could reproduce your fix please? :)

EDIT: I forgot to add the send(); command to the above. So i added the following and it now works!!

inline void disableAllLoops() {
        setSendBuffer(0x11,0x00);
        send();
    }

üdvözletem nekem olyan gondom lenne hogy a hang fagyási problémáim vannak és nem tudok rájönni hogy mi lehet a gond arduino nano 3 dfplayer mini Mpu6050 ezeket használom meg a Fx-saberOs programot de valamiért mindig van fagyási probléma mi lehet a gond

mindent beálítottam de valamiért folyton a hang beakad ezen a címen elészt peterfekete81@gmail.com

what???

The one before your message was written in Hungarian language, basically the guys was complaining about freezes with his setup.

@DUSTY36: I guess the problem might be a too high usage of RAM leading to instabilities. Can you specify for me how you configured the code? Especially if you have a neopixel blade with more than 120 pixels, stability problems can arise. The code is prepared for it however, so the worst thing what can happen will be that the system will be restarted by the watchdog.

If under "freezing board" you mean that the sound file keeps repeating, then you simply have a fake DFPlayer which is not fit for use. In this case make sure you have one with a genuine chipset from YX (that is a chineese company manufacturing these chips)

I want to use a Wemos ESP-32 module with 18650 batery holder. Does anyone know how to compile for it? I complains about avr/eeprom.h is not there. I think it’s the board issue. I compiles if I set the board for arduino Uno.

ESP32 doesn't have EEPROM, you would either need to use preferences or spiffs.

I am running into the same issue. Typically it loops whenever I turn the saber off. It will play the saber shut down over and over.

I have ordered some new DFPlayer’s with the YX chip… hopefully that will fix it.

Greetings Arduino community!

1) I’m looking for someone that can help me with a bring-up of Arduino on a new platform. To simplify the task this new controller will mimic a prior popular Creative Commons design (proffieboard) (https://fredrik.hubbe.net/lightsaber/v4) and provide similar features (strip LED, color profiles, possibility of accelerometer integration with smooth swing, flash on clash etc). Looking for someone with some prior experience or strong firmware skills to help get this project underway.

2) Secondarily I’m also looking for someone that can assist in saber application development. This can be Python or other scripting to develop the observable aforementioned behaviors.

This new controller design once completed will be sent to our pcb design house and will be available to the public once our final build is complete.

Payment for this project will include the final production saber and is open to negotiation. This is an opportunity to work with an extremely exciting product and should serve as a wonderful new stepping stone for the sabering community and other DIY builders.

For more info please feel free to contact me directly at: theultimatesaber@gmail.com

?

1.) What would be any different than the retail boards? (plecter/naigon) * feature wise

2.) What is any different from the number of DIY solutions out there? * what different features? (and why?) * why would I (as a consumer) want your new board over these others?

I see you also posted at the fx0sabers forum too....(good luck)

I'm not sure I really understand your intent here?

Its like some saying "I want some to help make a new car" (when there tons of different cars already exist)

probably cheaper to just buy one, thast fits your needs..

Is your new board planning on being open source as well or closed? and sold for profit?

What do you mean by this: "Arduino on a new platform"?

And the Arduino Saber Story is continuing…

I’ve been working on a new development for some months now pondering on what could be the next step in saber board design. Looking at the existing portfolio of established board manufacturers and open-source boards, we have seen an awesome development since the DIYino Prime board started the open-source revolution back in 2015.

Powerful processors, mid- to high-end motion engines, installation optimized board layout, USB-charging, cheap boards, quality boards, programmable boards, GUIs, advanced power saving, you name it. Not to mention the features implemented in software, SmoothSwing, full features with single button, neopixel animations, etc., all of which were implemented by the community whose cradle this very Arduino forum was.

I came to the conclusion that there is only one thing not existing yet, which would be a great addition, opening up endless new possibilities: a board having all these AND integrated Bluetooth capability.

Therefore I made research into what is required to build a over-the-air controllable board with BLE. Most major industrial nations require a certification in order to sell Bluetooth capable devices, so that was what I’d been looking for. And I found the ideal candidate: the new board will be built around a ready-to-use BL module, which is certified for all the countries where a certification to use a BL device is needed: MDBT42Q.

This beauty integrates an nRF52 chip from Nordic, which in turn has an ARM Cortex M4F. I.e. it has one of the most powerful 32-bit controller cores on the market, with 512k Flash and 64k RAM. I dubbed this new Board

DIYino Infinity

, as it offers nearly infinitely more resources than the AVR open source sabering started with. Infinity is engineered for perfection and quality without compromises known for all DIYino boards: I use the world’s most advanced PCB design tool for professionals. It is developed with the full power of two expert EEs, using state-of-the-art Design Rules. More, it will be among those few boards which utilize 4 layers for routing, therefore it will have the highest density of features on the smallest PCB possible. I guess this is already formidable, but I haven’t mentioned the best part: it is designed by someone who actively builds sabers Oh yeah, Infinity will be infinitely and definitely open-source, both in hardware and software.

The CPU of the BLE module has one more unique feature I instantly fell for: all of the pins can be configured for all possible functionalities. I.e. all 7 GPIOs available in addition to all signals controlling the motion engine, audio amp, power saving and UART link can be used for PWM, SPI, I2C etc. This makes the board ideally suited not only for saber boards but a whole range of other props and creations. The board supports USB charging of a single Li-Ion battery cell and has provisions to connect an external USB breakout board for both charging and programming the board, without the need to access the board itself. Well, not to mention that once BLE is up and running the saber can be interacted with, including config settings, from a smart phone or PC.

The CPU of the BLE module has one more unique feature I instantly fell for: all of the pins can be configured for all possible functionalities. I.e. all 7 GPIOs available in addition to all signals controlling the motion engine, audio amp, power saving and UART link can be used for PWM, SPI, I2C etc. This makes the board ideally suited not only for saber boards but a whole range of other props and creations. The board supports USB charging of a single Li-Ion battery cell and has provisions to connect an external USB breakout board for both charging and programming the board, without the need to access the board itself. Well, not to mention that once BLE is up and running the saber can be interacted with, including config settings, from a smart phone or PC.

The CPU of the BLE module has one more unique feature: all of the pins can be configured for all possible functionalities. I.e. all 7 GPIOs available in addition to all signals controlling the motion engine, audio amp, power saving and UART link can be used for PWM, SPI, I2C etc. This makes the board ideally suited not only for saber boards but a whole range of other props and creations. The board supports USB charging of a single Li-Ion battery cell and has provisions to connect an external USB breakout board for both charging and programming the board, without the need to access the board itself. Well, not to mention that once BLE is up and running the saber can be interacted with, including config settings, from a smart phone or PC.

Currently board bring-up is progressing well, most of the integrated modules, including the capability to connect to a smart phone are up and running! Keeping the fingers crossed and very excited about this new prop board.

+1

Yes, but not just any +1, but one from the original creator of Open Source Saber Boards! :)