I'm trying to convert the accelerometer values provided by the following dataset to train the intel curie KNN chip of an Arduino 101 to recognize walking and running actions:
https://github.com/mmalekzadeh/motion-sense
This dataset is collected by using an Iphone 6s accelerometer. Since I want the arduino to be able to recognize walking and running by using its own accelerometer (not the iphone one), I need to convert the dataset to the same data rapresentation used by arduino 101 (bytes). How this can be done?
This is what I did:
1) Found Iphone 6s accelerometer datasheet. The Iphone 6s (just like the Iphone 6) has two different chips, but probably this is the one used in the dataset.
2) Found Curie chip acceletometer datasheet. Available here
3) Iphone data is expressed in both gravity and userAcceleration per axis, while Curie chip only return a 4 bytes values per axis. Here is written that Iphone total acceleration is the sum of gravity and userAcceleration...but which is the unit used to represent this value? I think G units...but I'm not sure...
Update: The dataset is expressed in G units with sensitivity range of ±8g. To convert data from Gs, the formula below posted by L. Putvin can be used.
If you want to recognize walking and running you will need to use the 8g or 16g range if you want to be safe (the max needed will also depend on where the sensor is worn, as the accelerations are greater for certain parts of the body than others). You must decide which one first, and then you will multiply the G rating from the phone by the LSB number.
Sensitivity (calibrated)
— (A): ±2g: 16384 LSB/g
— ±4g: 8192 LSB/g
— ±8g: 4096 LSB/g
— ±16g: 2048 LSB/g
When you setup the arduino you will need to change the sensitivity from the default value when you switch to the internal sensor.
Related
I have connected and tested the two break-board versions of MPR121 Proximity Capacitive Touch Sensor Controller with various mcu's (ESP32, RPI pico, ARDUINO)
The one on a keypad version (Sparkfun compatible) and the one that you can connect custom pads to it. I tried them both with cpp and micropython. I connected them via I2C and everything is functioning on all occasions, with the IRQ option as well.
However I have trouble increasing sensitivity and by that I mean that if I place even a thin piece of paper or other layer before the touch pads, I can't get a touch signal.
Looking into the MPR121 micropython example Library I modified the following:
MicroPython MPR121 capacitive touch keypad and breakout board driver
https://github.com/mcauser/micropython-mpr121
Inside this library I see the following parameters for tuning that I tried:
# Set touch and release trip thresholds
#self.set_thresholds(15, 7) default....
self.set_thresholds(15, 7)
# Set config registers
# Debounce Touch, DT=0 (increase up to 7 to reduce noise)
# Debounce Release, DR=0 (increase up to 7 to reduce noise) .....default was 0x00
self._register8(MPR121_DEBOUNCE, 0x00)
# First Filter Iterations, FFI=0 (6x samples taken)
# Charge Discharge Current, CDC=16 (16uA) .default was 0x10 5-30 less to more sensitive
self._register8(MPR121_CONFIG1, 0x30)
# Charge Discharge Time, CDT=1 (0.5us charge time)
# Second Filter Iterations, SFI=0 (4x samples taken)
# Electrode Sample Interval, ESI=0 (1ms period) .default was 0x20 5-30 less to more sen
self._register8(MPR121_CONFIG2, 0x20)
I tried various combinations but the effect is minimal if non-existent. My target or best case scenario is to be able to place a 3mm plexiglass on top of the breakout board or custom pads.
I have four DS18B20 temperature sensors connected to my Raspberry Pi. I use 1wire and a pull-up resistor.
I read the values directly via cat from the 1wire devices and put the velues without calculation into a gnuplot data file.
The setup has been running fine for weeks now, measuring a coolbox at different places in a range between about 0°C and 30°C. I got quite accurate readings and plots.
But suddenly the values of all sensors start to "flutter", the became unstable. They also dropped -- all four -- about quarter of a °C. The flutter is about about 0.1°C to 0.2°C. Two of the sensors are actually inside fluid (0.5l and 25l) and thus it is virtually impossible that they suddenly drop or flutter.
The time of the event coincides with me checking the cooler box. I might have shifted or touched some sensoring parts. But can that explain the temperature shift? What happend? How can I fix it?
It seems that a cause of the problem could be resolution being lowered. This is a (volatile) setting stored in the sensor itself. It can be set to 9, 10, 11 or 12 bits. The higher the resolution the more precise the measurements will be, but at a cost of longer measurement time.
According to DS18B20 datasheet, by default the resolution is set to 12 bits after power up. In addition, the drivers handling 1-wire communication with the sensor often also by default set highest possible resolution during startup. This could explain why rebooting fixed the problem in case of OP, but doesn't explain why the change in resolution happened in the first place. That likely depends on the specific setup and will likely have to be resolved on a case-by-case basis.
Furthermore - to confirm that the measurements are indeed done at lower resolution, one can get the numeric values of the samples and check the minimum value by which the measurements change. For example, for 12bit resolution the minimum delta is 0.0625 degrees, while for 9bit resolution it may only change by 0.5 degree and nothing in between.
I'm trying to do target recognition using the target acoustic signal. I tested my code in matlab, however, i'm trying to simulate that in C to test it in tinyOS using sensor simulator.
In matlab, i used wav records (16 bits per sample, 44.1 sample rate), so for example, i have a record for a certain object, lets say cat sound which of 0:01 duration, in matlab that will give me a total of 36864 samples of type int16 ,and size 73728 bytes.
In sensor, if i have [Mica2 sensor: 10 bits ADC (but i'll use 8 bits ADC), 8 MHz microprocessor, and 4 Kb RAM. This means that when i detect an object, i'll fill the buffer with 4000 samples of type uint8_t (if i used 8 KHz sample rate and 8 bits ADC).
So, my question is that:
In matlab i used a large number of samples to represent the target audio signal(36864 samples), but in the sensor i'm limited to only 4000 samples, would that be enough to record the whole target sound?
Thank you very much, highly appreciate your advice
I have been following a tutorial that enables you to play around with the TXPOWER parameter of your wifi card / wifi adapter:
http://null-byte.wonderhowto.com/how-to/set-your-wi-fi-cards-tx-power-higher-than-30-dbm-0149606/
You can easily boost up your wifi range when increasing the TXPOWER.
Now, most people want to improve their wifi signal strength of their home router, right. But in my case, I would like my home router (which runs on a raspberry pi) to have a relative small wifi signal radius (say, a radius of 2 meters), so that you actually need to physically look for the pi home router when trying to connect to it.
I have learned that this tutorial does not do a thing with the wifi link quality and/or the wifi signal level and thus does not influence the wifi radius of my pi home router.
link quality & signal level
Do you guys have any ideas/thoughts about how to decrease link quality and/or wifi signal level (e.g Link Quality = 12/70 and Signal level =-10dBm) ? Is this even possible ?
I am using a Tp-Link TL-WN722N IEEE 802.11n USB - Wi-Fi Adapter.
WIRELESS LITE N ADAPTER 150M USB HIGH GAIN 1DETACHABLE ANTENNA WL-AP.
150 Mbps - External
First, I recommend reviewing this section from your link:
QUICK DECIBEL UNDERSTANDING:
Every 10 decibels is a 10X increase in power starting from 1 dBm equal
to 1mW... 10 dBm equals 10 mW, 20 dBm equals 100 mW, 30 dBm equals
1000 mW, and so on. Every 3 decibels is approximately double that of
the prior power, so 30 dBm is 1000 mW, if we add 3 dBm, then we can
double the power such that 33 dBm is about equal to 2000 mW.
It appears to me that you are able to modify the transmit power of your adapter as the tutorial states. Are you saying this is not working? If you set your transmit power to something extremely low (-30dBm, for example) you would effectively be turning off the transmitter. Keep increasing that value until you get your desired coverage radius.
If the transmit power parameter is not functioning as per the tutorial, then there are other means to achieve reduced coverage. The model you specified has a detachable antenna....so detach it. This would definitely reduce your coverage. However, if it reduces coverage too much, you could simply add an inline attenuator. Fortunately, your antenna uses an SMA connector which is very common. You can find many SMA attenuators on ebay with different attenuation values. Experiment with different values until you get the desired coverage.
And if that doesn't work, just wrap a bunch of aluminum foil around the thing lol.
Is the 127 note values in MIDI musically significant (certain number of octaves or something)? or was it set at 127 due to the binary file format, IE for the purposes of computing?
In the MIDI protocol there are status bytes (think commands, such as note-on or note-off) and there are data bytes (think parameters, such as pitch value and velocity). The way to determine the difference between them is by the first bit. If that first bit is 1, then it is a status byte. If the first bit is 0, then it is a data byte. This leaves only 7 bits available for the rest of the status or data byte value.
So to answer your question in short, this has more to do with the protocol specification, but it just so happens to nicely line up to good number of available pitch values.
Now, these pitch values do not correspond to specific pitches. Yes it is true that typically a pitch value of 60 will give you C4, or middle C. Most synths work this way, but certainly not all. It isn't even a requirement that the synth uses the pitch value for pitches! MIDI doesn't care... it is just a protocol. You may be wondering how alternate tunings work... they work just fine. It is up to the synthesizer to produce the correct pitches for these alternate tunings. MIDI simply provides for a selection of 128 different values to be sent.
Also, if you are wondering why it is so important for that first bit to signify what the data is... There are system realtime messages that can be interjected in the middle of some other command. These are things like the timing clock which is often used to sync up LFOs among other things.
You can read more about the types of MIDI messages here: http://www.midi.org/techspecs/midimessages.php
127 = 27 - 1
It's the maximum positive value of an 8-bit signed integer, and so is a meaningful limit in file formats--it's the highest value you can store in a byte (on most systems) without making it unsigned.
I think what you are missing is that MIDI was created in the early 1980's, not to run on personal computers, but to run on musical instruments with extremely limited processing and storage capabilities. Storing 127 values seemed GIANT back then, especially when the largest keyboard typically has only 88 keys, and most electronic instruments only had 48. If you think MIDI is doing something in a strange way, it is likely that stems from its jurassic heritage.
Yes it is true that typically a pitch value of 60 will give you C4,
or middle C. Most synths work this way, but certainly not all.
Yes ... there has always been a disagreement about where middle C is in MIDI. On Yamaha keyboards it is C3, on Roland keyboards it is C4. Yamaha did it one way and Roland did it another.
Now, these pitch values do not correspond to specific pitches.
Not originally. However, in the "General MIDI" standard, A = 440, which is standard tuning. General MIDI also describes which patch is a piano, which is a guitar, and so on, so that MIDI files become portable across multitimbral sound sources.
Simple efficiency.
As a serial protocol MIDI was designed around simple serial chips of the time which would take 8 data bits in and transmit them as a stream out of one separate serial data pin at a proscribed rate. In the MIDI world this was 31,250 Hz. It added stop and start bits so all data could travel over one wire.
It was designed to be cheap and simple and the simplicity was extended into the data format.
The most significant bit of the 8 data bits was used to signal if the data byte was a command or data. So-
To send Middle C note ON on channel 1 at a velocity of 56 A command bytes is sent first
and the command for Note on was the upper 4 bits of that command bit 1001. Notice the 1 in the Most significant bit, this was followed by the channel ID for channel 1 0000 ( computers preferring to start counting from 0)
10010000 or 128 + 16 = 144
This was followed by the actual Note data
72 for Middle C or 01001000
and then the velocity data again specified in the range 0 -127 with a 0 MSB
56 in our case
00111000
So what would go down the wire (ignoring stop start & sync bits was)
144, 72, 56
For the almost brain dead microcomputers of the time in electronic keyboards the ability to separate command from data by simply looking at the first bit was a godsend.
As has been stated 127 bits covers pretty much any western keyboard you care to mention. So made perfectly logical sense and the protocols survival long after many serial protocols have disappeared into obscurity is a great compliment to http://en.wikipedia.org/wiki/Dave_Smith_(engineer) Dave Smith of Sequential Circuits who started the discussions with other manufacturers to set all this in place.
Modern music and composition would be considerably different without him and them.
Enjoy!
127 is enough to cover all piano keys
0 ~ 127 fits nicely for ADC conversions.
Many MIDI hardware devices rely on performing Analog to Digital conversions (ADC). Considering MIDI is a real time communication protocol, when performing an ADC conversion using successive-approximation (a commonly used algorithm), a good rule of thumb is to use 8 bit resolution for fast computation. This will yield values in the 0 ~ 1023 range, which can be converted to MIDI range by dividing by 8.