Hi Bill, hi developers, thank you for your answer.
I've tried to check the specification of BLE beacons: They use only 3 Channels for 'connection-less' beacons, e.g. https://github.com/AltBeacon/spec (channels 37, 38 and 39, spread over the Bluetooth/WiFi frequencies). Further they send the same signal on all of the 3 channels during the same beaconing period. ("we need to advertise on all of the channels to be sure to hit whichever channel our gateway happens to be listening to.") I also found a blog with researches about the maximum beacon density: https://blog.ruuvi.com/bluetooth-beacon-density-maximum-92bcb947ee99?gi=801aae0b4f88 As far as I see the radio link should be as reliable as possible and able to deal with a great amount of persons in a room, train, stadium etc. Additionally there are a lot of other beacon signals used for other purposes on the same frequencies. They are quite likely to send beacons not to often to save battery. On the other hand a dangerous contact should be registered safely including the time how long the contact occurred. So I'd thought about this could be soled by a variant of one of the great protocols you have developed for us hams. As there seems to be no API in Bluetooth to directly generate or receive GFSK signals this might not be a quick win, but perhaps this time makes it possible to compile a new protocol standard for this type of transmissions, based on your experience. It seems that the project has already connections to the Bluetooth standardization group / smartphone developers as they have already needed some changes in APIs to soles other issues. Additional background (as I understood the discussed issues of the open source project https://github.com/DP-3T): A tracking App should be reliable to log contacts but also to provide data protection not using centrally managed private keys nor predictable beacon-IDs. The beacon-ID changes by time so it gets important to receive as much IDs as possible to be able to do a pattern recognition when a daily secret key of a positive tested person is provided anonymously to locally check if any beacon-IDs are received from this person during a contact period. Just asking if you were interested in getting in touch with the developers to found a task force to improve Bluetooth for this new challenge. This could help to improve one of the future versions of COVID-19 tracking apps. Thank you for everything es vy 73 Torsten, DL1MHJ Am 09.05.20 um 14:50 schrieb Bill Somerville: > On 09/05/2020 13:29, DL1MHJ wrote: >> Hi Joe, hi developers, >> >> First of all, thank you so much for your nice work and the time you are >> spending for developing >> WSJT. I am happy to use mostly FT8 on short wave. >> I am sorry, I haven't found a better list where I can reach you, I am hoping >> it's OK for you. >> >> I've read some issues about the open source project developing a >> decentralized tracking App for >> Covid-19 based on radio beacons via Bluetooth (https://github.com/DP-3T). >> Bluetooth signals might >> get overlapped und undetectable with a lot of persons nearby, e.g,. in a big >> room, public transport. >> So I remembered your nice and robust solution to use a frequency passband >> channel more effectively >> for many stations for FT4 etc. >> Do you think that one of the faster modes, e.g., JT9H could help for this >> development? >> >> Could you read this issue on their project page, please: 'How to protect >> against overlapping >> signals? (https://github.com/DP-3T/documents/issues/245) >> >> Is this something that you could think to support with your great knowledge >> and solutions you have >> developed for us hams? >> >> Thank you so much es vy 73 >> Torsten, DL1MHJ > > Hi Torsten, > > as far as I know the Bluetooth Low Energy (BLE) and Bluetooth facilities on > smartphone and other > devices only expose a high level API that allows identification and message > passing. I don't think > there is any access to the lower level layers, and certainly not to the > physical layer where > modulation is applied to the radio. > > I believe Bluetooth and BLE use a frequency hopping scheme to avoid > collisions within the mode's > 2.4 GHz channels, that would also be implemented in layers of the protocol > well below the API > accessible to applications. > > 73 > Bill > G4WJS. > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
