Help Requuest for Parkinsons glove development

[aeric]

1, I think a CSV file would be sufficient,

Maybe. It can also be a plain text file, json or xml format.
Instead of sending the csv file by email or FTP to a server which eventually landed into a database, there are other options such as using jRDC2 or REST API.

2. Data processing not required in app

What is the frequency of the data? What is the format?
Knowing how the data looks like will help choosing which way is more suitable to store it.

e.g the glove will send an array of numbers to the mobile every cycle.
The cycle is something like {1, 4, 2, 3, 13, 1, 3, 4, 2, 13, 3, 4, 1, 2, 13} where 1 to 4 represent the fingers and 13 is a pause.

Let say this cycle will repeat every 10 seconds. If the user use it for 3 hours then it will contain 3 x 60 x 6 cycles = 1080 cycles, which translate to approximately 1000 rows of data. If he/she uses it in a month, 3 days per week, it will turn to 12,000 rows of data.

Each row also record the date and time. So the format may look like:
{2024-05-09 08:00:10, 1, 4, 2, 3, 13, 1, 3, 4, 2, 13, 3, 4, 1, 2, 13}
{2024-05-09 08:00:20, 3, 4, 1, 2, 13, 1, 4, 2, 3, 13, 1, 3, 4, 2, 13}
{2024-05-09 08:00:30, 1, 3, 4, 2, 13, 1, 4, 2, 3, 13, 3, 4, 1, 2, 13}

e.g Another format is just the start and end time of the usage.
start time: 2024-05-09 08:00:10, end time: 2024-05-09 11:05:30

My preference is to use an SQLite database in the mobile. For simplicity, a KeyValueStore library can also do the job.

 

[emexes]

IOS doesn't talk nicely to Classic BT

Now that you mention it... that does ring a strong bell.

BLE FTW.

 

[stevewidget]

Hi Aeric
frequency of the data is not very complicated, and should not be more than twice a day!!!
I only need to know the date time and duration of the treatment and efficacy ( user input 0-9)
I would suggest the following
YY, MM, DD, HH, mm , duration, Efficacy <CR><LF>
All in plain ASCII. Duration could be number 1-9 in 30 min increments, and efficacy 0-9 as mentioned.
I don't need the time to the second. There is no precise answer from analysing this data, just trends.

Maybe. It can also be a plain text file, json or xml format.
Instead of sending the csv file by email or FTP to a server which eventually landed into a database, there are other options such as using jRDC2 or REST API.

Why???
The big advantage of CSV as far as I am concerned is it is universally recognised, a months worth of data is only 20x2x30 bytes. I could ask almost anyone to analyse it. I'm sure that the formats you mentioned are familiar to you and "easy", but without looking it up I have no idea what jRDC2 is and neither will the clinician who will be the ultimate recipient of this data. But I am open to being persuaded that there is merit in choosing an alternate format.
I guess if you want to work in jRDC2 in an SQL database that's your choice, and I accept that it may well make life easier for displaying usage on the phone, but when its exported I would prefer it in CSV as above please.

Am I to understand from your general comments that you are considering helping in this project ?
Again thank you for your input
Steve
PS I have received an offer to help in a PM. It seems I don't have the right to reply in this forum???? Either way does it make any sense for this to be a cooperative venture with say someone experienced in BLE side doing that and someone else doing the data handling for example.
Would the person who sent me the PM (and anyone else interested!!!) mind posting here what parts of the project they would like to handle.

 

[aeric]

Hi Aeric
frequency of the data is not very complicated, and should not be more than twice a day!!!
I only need to know the date time and duration of the treatment and efficacy ( user input 0-9)
I would suggest the following
YY, MM, DD, HH, mm , duration, Efficacy <CR><LF>
All in plain ASCII. Duration could be number 1-9 in 30 min increments, and efficacy 0-9 as mentioned.
I don't need the time to the second. There is no precise answer from analysing this data, just trends.

Why???
The big advantage of CSV as far as I am concerned is it is universally recognised, a months worth of data is only 20x2x30 bytes. I could ask almost anyone to analyse it. I'm sure that the formats you mentioned are familiar to you and "easy", but without looking it up I have no idea what jRDC2 is and neither will the clinician who will be the ultimate recipient of this data. But I am open to being persuaded that there is merit in choosing an alternate format.
I guess if you want to work in jRDC2 in an SQL database that's your choice, and I accept that it may well make life easier for displaying usage on the phone, but when its exported I would prefer it in CSV as above please.

Am I to understand from your general comments that you are considering helping in this project ?
Again thank you for your input
Steve
PS I have received an offer to help in a PM. It seems I don't have the right to reply in this forum???? Either way does it make any sense for this to be a cooperative venture with say someone experienced in BLE side doing that and someone else doing the data handling for example.
Would the person who sent me the PM (and anyone else interested!!!) mind posting here what parts of the project they would like to handle.

The advantage of using SQL database for me is it is easy to add, delete, update, search, sort and do analysis by SQL command such as count, sum, average, etc. It is more powerful than CSV and more maintainable. Using CSV is fine if you don't need all these fancy functions.

After I read more, I get the impression that the mobile app doesn't necessary need to link to the glove. The glove does not need to be part of an IoT. The mobile app can be a standalone app where all the output is supplied by the user manually. It is more like providing a form for the user input. Maybe I have misunderstood.

Honestly, I have some interest on this project. Due to some personal reason I afraid I can't help. But if you need help on any question regarding B4X, I am willing to give my answer.

 

[emexes]

Duration could be number 1-9 in 30 min increments

Would be better in standard units such as minutes. Using number 1-9 (or letter A-I) adds another translation step that needs to be known and performed.

Similarly with date and time, I would tend towards @aeric's ISO style because it is more recognisable as such to both spreadsheet import and Mk1 eyeball. Data that identifies itself is (almost) always a good thing.

 

[stevewidget]

Hi Aeric,
you are right the glove does not need to be involved in IOT , the only advantage is that the usage is recorded automatically. There is a serious problem with vulnerable ( rather than necessarily just old) people in that they forget if they have taken medicine and how much and when, I could instead use a pen and paper, and perhaps for some I will have to, but that doesn't guarantee that they will write every time. ALL it needs to communicate is that a request to start treatment for N minutes was started at Time, and perhaps acknowledged when completed or aborted. The app could sniff every few minutes to see if still alive. This is the sort of stuff I haven't yet fully defined.
Thanks also to em exes
Valid comments, just spent too long trying to save byte here or there. There was allegedly a quote from Bill Gates that "Nobody will ever need more than 640K of RAM", and Ive sorta stuck to that , especially with Micros

Thanks both
Steve

 

[personalapps]

I am curious to know the following:
1. Will the BLE app keep its connection till the vibration cycle is complete ? If connection is lost, how will we know end of cycle or interruption of cycle?
2. Is there an event in coin vibration motor which will indicate if it is vibrating or at rest?
3.Is there a specific sequence of vibration : Eg: Finger 1,2,3,4 or 4,3,2,1 etc.

 

[stevewidget]

Thanks Personalapps,
Just for clarification, this is not my project, but something Ive seen and thought could be improved. My ideas on what those improvements are is the reason for this posting, and my almost totally lack of knowledge with B4X and complete lack of experience with Mobile development, especially IOS.
All I have done is put together a prototype as outlined in the second YouTube using the the software I posted was from the Github page mentioned
github.com/pdbuzzboard/pdbuzzboard
The Arduino can be autonomous, the BLE is only for recording usage and user feedback. Exactly how its done is the reason for the posting.
1. The software I posted ParkyC3 is first stab at porting to ESP32-C3 and has a fixed timing loop as controlled by a single button. The BLE solution I see sending down down a variable to set loop time. What happens if phone disconnects etc is subject to discussion
2.I think it will be almost the same feedback as driving an LED, ie you can see/feel it.
3. The sequence is VERY important,and again is outlined on the Github. The ability to change sequence timing via BLEwould be a big plus.
Steve

 

[emexes]

I intend to use an ESP32-C3

How close are you to having one of these, and being able to program it via USB from Arduino IDE?

same as it sounds like you might already have done with a regular Arduino:

I have built a unit

or is "unit" currently just the glove and motors, not yet hooked up to a microcontroller?

I think this should also be written in B4R rather than Arduino.

It might be better to stick with Arduino IDE, to simplify use of existing ESP32 BLE libraries.

 

[personalapps]

3. The sequence is VERY important,and again is outlined on the Github. The ability to change sequence timing via BLEwould be a big plus.
Steve

Would that be the Tass 3:2 Pattern as shown in https://github.com/pdbuzzboard/pdbuzzboard/blob/main/GloveNano.ino :

// Define all 24 Random Sequences
unsigned int Seq[]={/*0x1234,*/0x1243,0x1324,0x1342,0x1423,0x1432, 0x2134,0x2143,0x2314,0x2341,0x2413,0x2431,
0x3142,0x3124,0x3214,0x3241,0x3412,0x3421, 0x4123,0x4132,0x4213,0x4231,0x4312/*,0x4321*/ };
int nSeq = sizeof(Seq)/sizeof(int);

 

[stevewidget]

Hi Emexes,
Yes I have the ESP32-C3 I intend to use for the first batch before building my own board, and yes I have built a working Arduino prototype currently out with a Parkinsons sufferer. So far it hasn't helped him a lot, but then he doesn't have a severe tremor problem, but Ive learnt enough to know he has no idea how often he has used it.
I agree there is no great advantage in writing in B4R, but as I said I thought I'd seen an example already done for in B4X, and I don't think I need any special Arduino Libraries. I really don't mind which.

Personalapps If you look in ParkyC3.ino posted earlier I used a Random167 example from the github page, but as yet there is no 'right' solution so I expect to experiment with various patterns.

My next plan is to try writing the app in Arduino using Serial rather than BT, perhaps I should have done this first.

Thanks again for your interest.

Steve

 

[emexes]

experiment with various patterns

That impressive-looking list of the 24 permutations of sequencing fingers 1, 2, 3 and 4, is later selected from randomly anyway, so it's not really a pattern, more just a complex way of shuffling four cards. Although it would make it easier to later implement a don't repeat same sequence twice in a row rule, so that's an advantage.

Maybe "pattern" refers to timing where fingers are buzzed for 12 time units and then left in peace (not buzzed) for 8 time units. Which might be the 3:2 ratio referred to by "Tass 3:2 Pattern", although that's also the on-off ratio of the discrete finger buzzes, so it could be that too. Or maybe both.

Presumably patterns/sequences you'd like to try, would look like the non-random patterns/sequences here:

from article "Coordinated Reset Vibrotactile Stimulation Induces Sustained Cumulative Benefits in Parkinson’s Disease".

 

[emexes]

I have the ESP32-C3 I intend to use for the first batch

In that case I was going to suggest getting the BLE link up first using the server-side example from:

ESP32 BLE Server and Client (Bluetooth Low Energy) | Random Nerd Tutorials

Make a BLE (Bluetooth Low Energy) connection between two ESP32 boards. One ESP32 is going to be the server, and the other ESP32 will be the client. The BLE server advertises characteristics that contain sensor readings that the client can read.

randomnerdtutorials.com

and test it using nRF Connect app.

Phase one would be a simple register where 1 = run and 0 = off.

Phase two could be to change that register to be the number of seconds (remaining) to run, eg write 0 to switch off, or 120 to run for two minutes. The same register could be readable, and return the down-counter value, eg write 120, then read it back 15 seconds later and it would return 105 (seconds left to run).

My next plan is to try writing the app in Arduino using Serial rather than BT, perhaps I should have done this first.

My experience has been that physical Serial (USB?) links between not-real-computers and mobile devices come with their own set of problems. And I have a recollection that Apple locked down serial connections pretty hard a few years back (about to go looking for the detail about that).

Detail found so far:

That’s basically correct. iOS has a lot of the same serial infrastructure as macOS but:
It doesn’t have built-in support for USB serial devices.
It doesn’t allow you to write your own code to add that support.

Unless you join the Made For iPhone program you can not directly connect anything to an iOS device unless you use Bluetooth or TCP/IP.

Access to the USB serial profile from an iOS device may require enrolling in the MFi program and manufacturing a special custom cable. See: https://developer.apple.com/programs/mfi/
Another possible option is to use Core Bluetooth to connect to a BLE serial port bridge device (Arduino,et.al.?). Core Bluetooth comm does not require MFi.