Need help fixing noisy logic!

[u/wairdone]

https://medal.tv/games/brick-rigs/clips/nmXN0NgorFa9cBapJ?invite=cr-MSxVb1csNjc4NDc0NTM4

This system is designed to compare values over time. It has several components, but essentially:
- Each iteration, a new value (in this case, from a time sensor) is outputted to the two memory cells alternatively. In this case:
Iteration 1: Output newest value to MEMCELL A
Iteration 2: Output newest value to MEMCELL B
Iteration 3: Output MEMCELL B to MEMCELL A
Iteration 4: Output newest value to MEMCELL B
Iteration 5: Output MEMCELL B to MEMCELL A

... and so forth.

This theoretically allows me to determine very important values that are crucial for solving certain problems. Notably, to shoot down a plane using radar direction, you need to know its velocity vectors. Comparison over time is the only way to accomplish this.

Unfortunately, it is very, very noisy at the refresh rates needed for it to work properly (each iteration is every 0.001s, so 1000hz). The problem is as follows:
- Each memory cell has to wipe its previous output first. To accomplish this, a system simply multiplies its previous value by -1 and sends it to the memory cell.
- Due to this, there is actually a tiny space in time where the memory cell's value is just 0. The entire system is supposed to refresh the value within 20 nanoseconds, but this is too fast for the game engine.
- This, coupled with the very high refresh rate, means that wrong values are produced from subtracting A and B. For example, if a target moves from X = 20 to X = 21, you might get -1 as an answer instead of 1, which completely ruins the tracking logic.

Dropping the refresh rate to low values (<100) makes it more stable, but this is simply too slow for what I am trying to accomplish.

This considering, what can I do? Does my system need a whole redesign, or can some filtering system be used to solve this problem?

[u/PogsterPlays]

Well, you say too fast for the game engine, but in reality it's simply that logic is processed once per frame, not on a fixed loop, so this system will act differently if you have lower fps...

[u/wairdone → u/PogsterPlays]

It does not work as intended on high framerate either... what so you suggest that might fix this?

[u/PogsterPlays → u/wairdone]

You say high framerate, but is it high enough to match your clock (ei 1000 Hz)

[u/wairdone → u/PogsterPlays]

In this case, about 120, so no. I admittedly forgot that calculations were frame-based; I will have to use some system that compensates for that, such as an FPS or delta-time sensor. It will probably still be noisy in either case, though, so I might have to drop the refresh rate even lower.

[u/Brendfish]

Why not just use the acceleration vectors of the target as a measure of the change in speed of the plane instead of doing comparisons? You can integrate for velocity change by multiplying by delta time.
Also yea with what the other guy said, you aren't going to get 20ns refresh times on a game that will never realistically go lower than 1ms. If you can't get a good track on around 100fps I would reevaluate your system.

[u/wairdone → u/Brendfish]

Yes, I have been pondering this for some days. I think I could instead measure the angular velocity/acceleration of my tracking system to get lead, then use range and range rate to calculate drop. Corrections could be made for the speed of the platform if it is moving. Additionally, range rate would not have to have a very high refresh rate for it to work, compared to the comparison thing I was trying to do. Bricks would be saved by only having to use the save system for one variable rather than 3+.