Technical Development
Interface software
1. Problem: Noisy sensors that don't provide clean ON/OFF (12.6.2020)
Answer Version 0.7.1a of the software provides the means to deal with this problem RHJ 17.6.2020
Hardware
1. Proposal to create an Arduino based unit to send orientation data from the dumbbell to the PC by Serial port or by UDP over Wifi. (12.6.2020)
Richard Johnston and Ben Johnson to discuss details (12.6.2020).
Update 17.6.2020 - Ben has collected preliminary data useful for determining bell position via Serial port from an Arduino from a dumbbell and it is very promising
2. Some proposals for improving dumbbell design R H Johnston 9 Jul 2020
Not directly relevant but may be helpful - a 2008 series of exchanges in Ringing World on mini-ring dynamics
Proposals
1 Suggestion by Alan Faiers:(14.6.2020)
Just a thought...
If each dumb bell sensor, and the Ringing Room server, were fitted with a GPS receiver then data sent to the server could include nominal sensor-to-strike delay and accurate timestamp. The server could assume the same propagation time would apply to the return journey and accurately calculate the time to send each individual signal.
Response from Richard Johnston 14.6.2020:
I imagine that what you can do in terms of obtaining data from a client's browser with Javascript is rather limited.
What ringingroom does at the moment is receive your keystroke at its server, and the server broadcasts that result to all the clients in the tower, so any difference between what they hear is the differences in their one way latency. The individual's latency to the server may also vary so that individual will appear to strike late to everyone, including himself.
What Graham John and I designed for Handbell Stadium was based on monitoring two way latencies on the UDP channels used for transferring data. This allowed the following scheme - get the typical 2-way latencies for everyone, and send out the data from the central server for the ones with low latencies later than the ones with high latencies so everyone gets the data at the same time. This works well unless someone has a very long latency (in which case the delay is bounded) and more especially the very long latencies that happen occasionally - this scheme got rid of the feeling that everyone else wanted to ring slower.
Comments (2)
Alan Faiers said
at 2:35 pm on Jun 14, 2020
Just a thought...
If each dumb bell sensor, and the Ringing Room server, were fitted with a GPS receiver then data sent to the server could include nominal sensor-to-strike delay and accurate timestamp. The server could assume the same propagation time would apply to the return journey and accurately calculate the time to send each individual signal.
R H Johnston said
at 4:00 pm on Jun 14, 2020
Hi Alan - you can log in and edit the page itself...
I imagine that what you can do in terms of obtaining data from a client's browser with Javascript is rather limited.
What ringingroom does at the moment is receive your keystroke at its server, and they is broadcasts that result to all the clients in the tower, so any differnce between what they hear is the differences in their one way latency. The individual's latency tothe server may also vary so that individual will appear to strike late to everyone, including himself.
What Graham and I designed for Handbell Stadium was based on monitoring two way latencies on the UDP channels used for transferring data. This allowed the following scheme - get the typical 2-way latencies for everyone, and send out the data from the central server for tbhe ones with low latencies later than the ones with high latencies so everyone gets the data at the same time. This works well unless someone has a very long latency (inm which case the delay is bounded) and more especially the very long latencies that happen occasionally - this scheme got rid of the feeling everyone else wanted to ring slower.
You don't have permission to comment on this page.