Pogopins difference

I ordered a batch of new pogopin connectors at the same supplier where I bought the first batch, sadly I noticed the new batch is slightly different size and swapped magnet orientation. So if you get those connectors for your ammo clips and blasters, get enough in ONE batch. I’ll add a modified version of the printable files soon.

ATTAG FRAMmo

Yes it has been a while since my last post however here is the first package with all the required data for the ammo clips.

ATTAG Frammo V1.3

First I started with blue clips and quickly found out that the light of the LED almost can’t pass the material. So I have picked yellow, also because it is easier to find in case you drop it when you are in a match. And I tried it with flying wires. Of course you can do it, but I can not recommend it because at the end the PCB aren’t really expensive at all and the money you invest in them you save on the wires you don’t require then.

So I opened fritzing and created a PCB (layout and link in the above file) and ordered a stack of them. Please don’t mind the circuit view in fritzing the soldering is pretty self-explaining in the pictures you see here.

Use the small display lift as you see in this picture:

Print as many of the cases as you need:

Solder like this:

Basically just GND,VCC,SC and SDA and the resistor for the LED. Soldering the pogopin connector is a bit tricky because the magnets attract the tip of the soldering iron but it is doable. Positive pin of the LED to the lower connection to the edge.

There you go, your stack of FRAMmo

By the way, all of this isn’t really required to make ATTAG work at the end, it is a nice addon and SOME game modes will require them. However, a cheaper way is to just leave the display out of them. The ammo left will be shown on the blaster display anyway. This here is just a fancy addon. I’ll add a case version without display window at a later point.

Last but not least, if you mess up your electronics or health by trusting in my work – your problem. No warranties given.

ATTAG ESP-NOW handshake working

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.

ATTAG audio and wifi update

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. 😉

ATTAG – multiple IR receivers #2

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.

much cleaner now… 🙂

ATTAG – some fun today

… wait, where does the white wire belong? 😉

Even though this works until now, I really need to put this on a double size breadbord and use short connecting wires.

However with this chaotic wiring I already checked the following:

  • I²C Display – working
  • I²C FRAM – working
  • ID Pot – working
  • Multi-Core with digitalread – working
  • DAC sound with PAM amplifier – working
  • WLED lights – working

ATTAG – how to for multiple IR receivers

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.

ATTAG – waiting for D32

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.

ATTAG – fighting with a diva called S3 Mini

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.

ATTAG – changing the address of an OLED display

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 soldering station, 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).