| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Technical Development - ways of making the ringing experience better

Page history last edited by R H Johnston 3 years, 7 months ago

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.