Just a small update, the handshake by ESP-NOW is working, I haven’t tested the range yet but this is not an issue which stops the PCB from being created, because the WiFi stuff is on the ESP MCU anyway.
I have chosen to overwrite the MAC addresses of the blasters with 0x00 to 0x0F (0-15). This isn’t really required and I already had multiple people complaining about this: “They already have unique addresses.” But in my eyes it makes things easier to handle. Take it or leave it, anybody can change my lousy code once it is released. 😉
I still have some headaches with audio, the ferrit beads don’t change anything except from consuming a lot of space, completely useless because without any effect. Not to mention that it is a real pia to get sound working on the server parallel to the lvgl graphics stuff. It is possible by moving the elements to seperate tasks but it still isn’t really good. The server doesn’t need to play any fancy sounds, just some beeps but that seems to be more difficult than playing a wav. Wav playing works but the DAC output is way lower than pushing a simple tone() to that pin, and the start game / end game signals need to be loud enough to hear them in 100m distance. Of course the blasters could signal too but that might end in a multiple sound chaos due to delays in start command receiption. Anyway, I am on it.
Now I spent like two weeks on the I2S audio stuff and I still can’t get it to work, I know it is sort of functional on the physical basis so it is okay how it is connected to the PCB but I think I’ll just put that aside for a moment because I am just too dumb for the code.
That just stops me from further progress and at least I got some audio working with the DAC path. I’ll just get back to I2S once I am done with the rest. The DAC stuff is far from ideal, especially about the noise and every electronical way to get rid of interference just didn’t turn out what I expected. I am still waiting for some ferrit beads to add, the capacitors mentioned in the PAM specs actually don’t make much difference.
For the WiFi communication it is a comparable situation, the LR mode simply doesn’t work and I don’t wanna wait until someone drops an eye on it at espressif. So I’ll do a step back and try ESP-NOW which should be able to achieve ranges around 200m outdoor and maybe even 50m indoor. I just hope this works better with the current espressif package than LR.
Meanwhile I ported the blaster code to platformio just as the server code. So at the end noone has to switch between Arduino IDE and Platformio. I’ll get more into detail how to use the code, once this is at release level. It will contain heavy inline documentation for almost every line of code, so even nobrainer like me can get it to work. 😉
I was testing the IR receiption using the IRMP lib with the D32 board now and it turns out it got the same issues like the S3, but at least it works in single core mode. However as soon as you try to put the IR listening to the second core, the D32 ends in a boot loop.
There probably is a way to fix this but meanwhile I put focus on the secondary microcontrollers für IR receiption. In the last post I attached a picture with a set of possible candidates. I suggest to drop those without TX/RX capabilities which are the ATTINY variants and go for one of the ESPs. The ESP-01 is the cheapest variant and got all required I/O to get the job done. Any other ESP8266 or ESP32 will do too but are actually an overkill for the small task.
Why TX/RX? It is the simplest way to send the information to the main board, for an ATTAG 2.0 version those could even communicate via wifi, so a hit receiver on a helmet or backpack wouldn’t require a cable. But that is nothing for the first release version. My lasertag experiences tell me additional hitpoints are not really important. As long as all players play fair, not covering the IR receiver.
Since it also needs to provide information who actually shot just an 0 or 1 isn’t enough. That is where the TX/RX comes in handy. All receivers will be connected to RX of the main board then, giving the opportunity of a flexible number of detectors.
Here the cleaned up breadboard with one working IR receiver ESP-01 connected to RX of the D32 board. Two things left to test, then I’ll get some PCB for a “release candidate”. First thing to test is the shutdown/wakeup of the PAM audio board. The static noises are just annoying so it makes sense to activate the amp only when it is required. I am not sure if the switiching will be fast enough though. Up to now I could just switch it off but not reenable it. Other way of course using some capacitors. Second, the IR sender. I had some working circuit already but it was a bit overkill and required two more diodes, the TIP120 is too big so I’ll go a step down to a smaller transistor.
The IR detection got one problem which needs to be solved, the IR libraries are only able to receive at one pin. Which means technically it would be possible to hardwire multiple reveivers but then there is risk of mixing valid and unvalid signals and it is never possible to detemine where you have been hit.
So I am going to try to get the source done to read from one pin directly connected to the mainboard plus an optional feature to read from other hitpoin pins.
This however requires the receivers to run on their own circuit.
For this you will be able to choose from a large variety of boards that can be programmed with Arduino IDE. Basically the one the right here ATTINY85 (with the chip missing) will most likely do. Others need a programmer, such as the second in the row. So it will be up to you what to choose, I’ll test this with multiple of these little friends, the ESP32 variations will be a total overkill though.
While I am waiting for the D32 as S3 replacement I already made the PCB for it, but before I get a sample of that I am going to check if it works with the pins I have chosen. This is a hybrid board for either I²S sound or the internal DAC using a PAM8302A amplifier. It doesn’t make a big difference in the price but maybe some of you want to pick what you already got. It also still got the HC-12 433MHz in mind, just in case it comes handy in the future again. Currently there is no fix for the WiFi LR mode available but maybe I have better luck with the D32 on this too. The sound of the I²S board is far better than on the 8KHz internal DAC though it requires more memory for higher quality sounds. I don’t want to add external memory even though it would be possible through the SPI interface for which I also reserved some solder eyes, just in case someone wants to use external memory. Don’t consider the circuit to be rock solid from the picture, it is an UNTESTED layout. I’ll provide the fritzing files as soon as this passed my tests and I got the first samples of it.
A nice feature of the D32 is the battery port, however the 3.7V will be probably too weak for the WLED, audio and for the IR. I am a total electronics idiot maybe it would be sufficient but I prefer a swappable battery pack like a power bank.
Since the beginning of ATTAG (OSDYLS) I switched the MCU multiple times, from D1 Mini to S2 Mini because I needed more GPIOs and now to S3 Mini. So I collected some experience with these little time eaters.
Let me say one thing at this point, the S3 Mini is a diva. Not sure if it is matter of revision number or of the core cpu or because it is relatively new. However, be prepared for some dramatic behaviour during the programming of it. It loves to block flashing from time to time or ends in boot loops if your code isn’t closely to what it likes. Don’t worry until now I was able to recover any of these, so it isn’t too easy to brick one to death.
First of all, make sure the IDE got CDC on boot “enabled” otherwise you won’t see any serial print outputs.
If it got stuck in a boot loop you need to reset it with the buttons, sometimes multiple times and/or remove/replug the usb cable. If it still doesn’t like to be flashed go to your console and manually execute the esptool command copied from the IDE output.
If it still refuses flashing add –no-stub to the parameters, like this: C:\esptool_py\4.5.1/esptool.exe –no-stub –chip esp32s3 –port COM6 –baud 115200 –before default_reset –after hard_reset write_flash -z –flash_mode dio –flash_freq 80m –flash_size 4MB 0x0 […]
So why the S3 at all if it is so complicated?
Because the D1 and S2 are single core computers, the S3 got two cores and that means one core can be reserved for “listening” to incoming signals. That way the detection of a hit is never interrupted by whatever else happens on the blaster.
So the “eyes” of the blaster will run in the main loop() of the code which is set to core 1 by default, all the trigger/display/ammo/audio will be put on core 0, if everything goes well.
Libs that work with interrupts tend to don’t work well with the IRremote library, such as the WLED control. I need to do some tests to figure that out, however the feedback on the WLED usually just happens when IR detection is not required. Such as hit feedback AFTER hit detection.
Another thing that I stumbled across is the fact that IRremote only allows ONE receiving pin, this makes it more difficult to add multiple hitpoints. There is an old fork of the lib with multiple inputs, I have to check if it works.
So that is the stuff I am currently working on, the Wifi LR / UDP thing is still unresolved, waiting for the guys @espressif to work on it.
In the requirements I mentioned a 128×32 pixel OLED in the optional stuff, if you are planning to use more than one display per blaster you will have to change the address of the 128×64 pixel OLED unless you get a 128×32 pixel OLED with changeable addresses.
This needs a bit more advanced soldering skills with SMD, which I never had to use before. However I succeeded with my first approach even though it looks pretty ugly. 😉
Remember this absolutely is NOT required for the functionality of the blasters, it is just a neat addon. But if you want to have it you should get a hot air solderingstation, to remove the SMD resistor from its current place.
The resistor is a 4.7K, just in case you kill it during the process. You need to remove it from position R11 (address 0x3C) and solder it to position R12 (address 0x3D).
As I wrote in a former post, I would test the laser power of the small IR laser. I got myself a tiny HWLPM-Mini 10W. It isn’t very accurate and usually measures up to 7% higher than the real power. The smallest step is 1mW and pointing the IR laser at it, powered with 3.3V coming from a D1Mini, it leaves the display of the laser-meter at 0.000W.
While the max voltage of the laser is 3.5V , the specs look pretty realistic with 0.6-0.9mW. So at 3.3V it probably will be around 0.7-0.8mW.
You may say the laser-meter is broken, no it actually isn’t. I tested two laser pointers at it and was a bit shocked, the blue one ends up at 28mW after 20 seconds, the red one at 6mW, so they are both far over the 1mW rate they are sold at and the blue is even far above the 5mW labeled sticker on it. So watch your eyes when using these.
Conclusion: The IR laser might actually be an option.
This post will be updated from time to time, the components might change, so it is up to you if you want to experiment on your own while in the “pre-release” state or wait for a release state. All items get a color status:
yellow = component might change blue = component is final choice, only chance of change is if insurmountable obstacles appear
The prices are those I payed for them and of course depend on the source where you get them. I am not related to any of these shops and I don’t get any bonus or affiliate payments, they are just a suggestion.
NOTE: Not in the list are basic items you will need for sure such as wires, solder, some glue and filament for the printed parts. For the JST connectors I don’t provide a link since there are offers with collections that make more sense including or not including tools etc.
Minimum requirements for ONE blaster, minimum means no audio or visual feedback and no blaster ID, which makes all of this pretty useless but you can fire at a target and the target gives feedback. Actually you just need the IR sender and receiver, one resistor plus the LOLIN S3. But hey, that won’t be fun at all.
Since the S3 Mini causes massive trouble with many libs I probably have to replace it again by something else, I ordered some ESP32 WROOM dual core boards to check them out and to compare their behaviour to the bitching of the S3 Mini.
I hope the S3 is still an option in the future (damn, I got ten of them 😉 ) but at the moment it suffers from incompatibility because the development of many important libs is still not aware of it or just doesn’t want to be aware of it.
