Methods to Address Nodes

Thanks for your help. I am looking into creating a wireless communication device that would control clay pigeon machines. My thinking is that the Heltec LoRa V3 would be the best starting point. I would have a main transmitter that would communicate to several receivers. 1 way communication is okay and I think each controller would control up to 4 relays that would launch the targets or change the angle of the machine.

I think I would like to be able to cotrol several nodes and I would like to be able to change the nodes when I reconfigure the course. I was thinking DIP switches would be the simplest way to address the nodes. Are there other ways to set the addresses that I should consider?

Also, are shields a thing with the heltec LoRa?

There is no concept of addresses in LORA, it's a free-for-all. You need to design a message protocol that MUST be very secure since guns are involved and must contain addressing data fields as well as Cyclic Redundancy Checks. LORA is quite simple to make, but designing a protocol that prevents others form spoofing you is the challenge.
Not sure what you mean by 'shields'
Start by reading the pinned post re 'How to get the best from the forum' then a photo of a hand drawn wiring diagram is fine. Post all code in code tags and any verbose error logs also in code tags. The Lora libraries contain sample code you can build off.

It is not clear what this means. Both transmitter and receiver have to know which is which.

If there are several receiver nodes, most people put the target node number(s) in each transmitted data packet.

Here is the URL you need to add to additional boards so you can install Lora boards.
https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series/releases/download/3.0.2/package_heltec_esp32_index.json
Here is the Boards to install


This is a good library and a screen grab of the samples

PLEASE remember to provide fail-safe physical isolators between the receivers and launchers… otherwise someone will lose a hand, finger or eye.

1 Like

Relays are old school, and can fail. Today we are more likely to use a MOSFET to control a motor or solenoid.

Your thinking needs to think about what control actually means. It means your program knows the status of each device so you can control it and know it completed the command and is ready for the next command. Your design seems to be shoot and pray that what was commanded actually happened. Do not short your control design!

So each numbered "station" consists of 2 machines that i will refer to 1a and 1b, 2a and 2b, etc. The transmitter would select the station and the receiver at each target launcher would know its designation based on its assigned . My thinking was using dip switches to assign each machine 1a to 1b to 2a to 2b, etc. As the course is adjusted, it would require resetting the DIP switches which would be pretty time consuming.

Is there another method that i should consider where you could easily adjust the receivers address without dip switches or connecting to a computer?

Thanks for the mosfet advice. This was helpful. I dont know current draws of each motor yet. With that being said, i think most of the launching machines have internal relays that I would be hypothetically switching with mosfets.

The launchers throw a colored disk and are not a firearm. However, they can hurt you if you stand right in front of them. So you dont stand in front of them when your downrange working on the machine and they have a power switch. A target shooter doesnt need to get near them.

Give each of the nodes a permanent unique ID number and arrange the node software so that the node only responds to packets for that unique ID number.

The central 'wireless communication device' just then needs to have a configuration that maps actual node locations, such as 'Location1A' to a particular unique ID. So re-mapping the course is done at the central device.

You would need to arrange that the central 'wireless communication device' configuration and mapping can be stored in local Flash, FRAM, EEPROM etc so that all is not lost in a power down reset situation. Or store sets of config maps on SD card.

You would also need to use a very robust packet protocol, so that external rogue LoRa packets or the internally generated LoRa phantom packets do not mess things up.

A concept of 'reliable' packets for LoRa is described here;

https://stuartsprojects.github.io/2021/08/25/Reliable-Packets-Part1.html

https://stuartsprojects.github.io/2021/08/26/Reliable-Packets-Part2.html

1 Like

The control is a button is pressed to tell the machine to throw a target. I need a short response time from remote (transmitter) to each of the target receivers (<100 ms). If the communication does not go through, there would be no target and you would press the button again. I dont think I need the receiver at the target to communicate that it launched a target; the shooter would see it in the air (or not).

On the other hand, and if this does not affect the lag between button and launch, I would consider adding protocols that would resend a command if unverified.

You’ve thought of everything…
except anyone else that doesn’t know when they’re going to fire, or animals, repair techs, low level staff reloading the disks etc….

sounds a workable project using a module such as Heltec WiFi LoRa 32(V3) using a simple P2P protocol
DIP switches are a common way to configure node parameters such as node addresses and IDs

my dude... its a 120 acre farm surrounded by other 100+ acre farms. The industry standard is that you don't stand in front of the machine when its is armed and you manually disconnect the battery and decock when you approach them. The trajectory is known when you approach the machine. What you are suggesting would be a significant violation of the standard of care of trained technician and shooters. Shooters have no reason to be down range. Technicians have training on how to operate the trap. Thanks for your concern.

Thanks for your feedback. I just came across these as well that I think would work for the receivers:

4 channels good for 2 amps at $29.80 us: https://www.makerfabs.com/lora-4-channel-mosfet-driver.html

4 channels good for 10 amps at $15.90 us: https://www.makerfabs.com/4-channel-lora-relay-10a.html

2 Likes

interesting devices ! useful links to technical details and sample code
what are the voltage/current ratings required to fire the clay pigeon machines ?
make sure you get the correct LoRa frequency for your country, see lorawan/frequencies-by-country

Sure thing. Im US so 915 mhz? Everything runs off a deep cycle 12 v battery. Most machines just have a cocker that runs 5-15 amps. There is a trigger that fires a relay internal to the machine, so i could just tap into the trigger thay should be well below an amp.

Trap machines go side to side. Wobble goes up and down. And there are tilt options. These would be the other 3 channels and i anticipate below 2 amps each when they run. I would probably develop a random number generator that would cycle these 3 channels for unpredictable durations.

In the alternative, i could fire nearby machines from 1 board.

Your major challenge is going to be getting reliable and timely data exchanges. A small delay in the 'pull' command and the clay actually getting airborne will bring heaps of scorn down upon your head. Shooters are accustomed to a timing and the good ones even adjust for different known pullers. Your minor challenges are power related, try to use MOSFETs NOT relays, one can fail over time the other not.

My requirements are less than 100 ms from command to launch of target. I think This could be reduced down to below 50 ms. It would be an interesting study to see how the average trapper performs.

My first round design will likely use relays until I can get current data and then I would likely use half - h bridge mosfets on the main arm and full h bridge mosfets on wobble, oscillator, and tilt motors. Regarding the arm, I think most machines use a limit switch that is bypassed by a button and that most of the current goes through the limit switch until it is opened again in the right position. A pretty rudimentary design. I don't need PWM or reversable motors, but the mosfets have that added benefit.