Yes, it is possible to synchronize Shimmer with a third party device. Refer to the following document for an example, which can be found on our documentation page:
- “Sync Shimmer With External System”
Although it is common practise to place the limb electrodes on the arms/legs, according to their names, in reality, all of the limb electrodes can be placed on the chest. The important thing is that each electrode should be placed on the body, away from the heart and in the direction of the joint to the relevant limb.
NOTE: When placing the electrodes on the extremities instead of the chest, longer cables are required. Using longer cables might result in a lower quality ECG.
The acceleration data needed for estimating the orientation in quaternion format can be acquired with either the wide-range accelerometer or the low-noise accelerometer, using one of our APIs or Instrument Drivers.
For estimating the orientation data from the data of the low-noise accelerometer (or wide-range acceleometer) + gyroscope + magnetometer we have implemented the MARG algorithm from:
Madgwick, S.O.H.; Harrison, A. J L; Vaidyanathan, R., "Estimation of IMU and MARG orientation using a gradient descent algorithm," Rehabilitation Robotics (ICORR), 2011 IEEE International Conference on , vol., no., pp.1,7, June 29 2011-July 1 2011, doi: 10.1109/ICORR.2011.5975346
In addition to the GSR connections, the Shimmer GSR+ unit has another input (3.5mm jack) that can be used to interface external analog (or digital) sensors with the Shimmer. In the shop section on our website we offer an Optical Pulse Sensing Probe or Ear Clip - analog sensors which capture a photoplethysmogram (PPG) signal from the finger of the test subject. From the PPG signal the heart rate (HR) of the test subject can be estimated when a PPG-to-HR algorithm is applied.
The answer to this depends on the firmware running on the Shimmer.
With SDLog firmware, you have two options using Consensys:
1. Enable the sync feature in the configuration panel to put the Shimmers into master/slave mode. As a result the slaves get timestamps synchronized to the master Shimmer after the data has been imported into Consensys.
NOTE: The master communicates with the slaves over Bluetooth, therefore you have to take the Bluetooth data latency into account. Also, during the experiment the Bluetooth adapter of the Shimmers switches on when synchronising, which uses power and limits battery life.
NOTE: If one of the slaves is power-cycled or switched off (e.g. when the battery gets empty) the synchronization information is still present.
2. Only set the real time clock (RTC) on each Shimmer, so that all Shimmers record data common to the PC clock.
NOTE: The Shimmers do NOT communicate over Bluetooth, therefore the Bluetooth module does not switch on and does not affect battery life.
NOTE: In all cases, do NOT reset or power-cycle the Shimmer to avoid losing synchronization information.
When using LogAndStream firmware and Consensys only the second option applies.
Data latency is the delay associated with acquiring a sample of data and transmitting it along a data communication line. It can be defined as the time difference between the moment that the measurement is taken and the moment that a reading of the measurement arrives at a particular point such as the PC serial port.
Due to the effects of data latency, data acquired from multiple Shimmers at the same time does not necessarily arrive at the PC at the same time. Experimental results have shown the data latency over Bluetooth to be variable. The same statistical distribution for the latency was found for the Shimmer-to-Shimmer and Shimmer-to-PC communication over Bluetooth, with a mode of approximately 25ms and a maximum value of 100ms.
The Shimmer has a real time clock (RTC). This RTC is automatically synchronised to the PC time using the Consensys software when a Shimmer is either connected over Bluetooth or docked in a Consensys Base or Shimmer Dock.
NOTE: The RTC memory in the Shimmer is volatile, i.e. the RTC information is lost when the Shimmer is reset or power-cycled.
The maximum allowed sampling frequency when using Consensys is 2048Hz. However it is important to note that at high sampling frequencies, packet loss can occur. The more sensors are enabled, the lower the maximum sample rate is before packet loss occurs. In the documentation recommended sample rates for capturing particular signals can be found.
NOTE: In case data is streamed over Bluetooth from a Shimmer to a PC or Android device, the maximum sample rate - before packet loss occurs - can also be limited by the Bluetooth adapter of the PC or Android device.
When the two GSR electrodes are connected to the skin of the test subject, a very small DCcurrent will flow from one electrode, through the skin between the electrodes, to the second electrode. The circuitry is designed to limit the maximum DC-current to protect the test subject.
Even in case of a first-order fault, the current will be much smaller than the threshold for causing harm. The current flowing when the GSR electrodes are attached to the skin is typically a couple of orders of magnitude lower than the threshold for feeling current.
First, the AgCl electrodes that we use are considered to be non-polarizing. Secondly, our circuit is designed to provide a low DC potential, reducing the effect of the counter-electromotive force.
Furthermore, for GSR measurement, the metric of interest is usually related to "activity" level or changes in the conductance, rather than focusing on the baseline values, which will slowly vary over time due to electrode-skin connection quality, temperature, et cetera. Thus, any slowly-varying component due to polarization is likely to be negligible for any practical application.
There are a couple of possibilities to explain what is going on:
Make sure the Shimmer is powered on. If you try to program the Shimmer when it is powered off you will receive an error. You may also receive an error if your Shimmer Dock has not been successfully installed, or the COM port is invalid or incorrect. If you are sure that the COM port is correct/valid, you may need to reload the device.
If using a Shimmer Dock: Remove the Shimmer from the Shimmer Dock and unplug the USB cable from the dock or PC. Then, reinsert the USB cable and dock the Shimmer again.
If using a Shimmer Base: Remove all Shimmers from the Shimmer Base, unplug the USB cable from the dock or PC. Unplug the power connection from the Shimmer Base. Then, reinsert the power cable, reinsert the USB cable and dock the Shimmers again.
For more information, refer to "Gettin Started with Consensys" on our documentation page.
The Shimmer dock exposes two serial ports; the host computer’s operating system will enumerate them sequentially, either as two com ports (in windows), ttyUSB ports (in linux), or tty.usbserial-FTT ports (in Mac OS).
The first is tied to programming pins on the Shimmer; the second accesses the Shimmer's uart0 pins.
When you dock the Shimmer, if you have com21 and com22, or /dev/ttyUSB0 and /dev/ttyUSB1, or /dev/tty.usbserial-FTT910SHA and /dev/tty.usbserial-FTT910SHB you program the Shimmer with the lower numbered/first port.
If you wish to communicate with the Shimmer’s serial port with host-side software, you would open the second port.
To these units: Shimmer3 / Shimmer3 Bridge Amplifier+ / Shimmer3 PROTO3 Deluxe, one external and one internal expansion board can be connected at the same time.
To the Shimmer3 PROTO3 Deluxe and Shimmer3 Bridge Amplifier+ units an internal expansion board can only be connected when the PROTO3 Deluxe Expansion Board / Bridge Amplifier+ Expansion Board, (which is an internal expansion board itself) is removed.
The Shimmer3 GSR+ unit, the Shimmer3 ECG unit and the Shimmer3 EMG unit can only accommodate an external expansion board. These units are so called "unified boards", i.e. the enclosure contains only one PCB (instead of two separate ones) that "unifies" a Shimmer3 mainboard with an internal expansion board; a GSR+ Expansion Board or an ECG/EMG Expansion Board.
Yes. The ShimmerSensing LabVIEW Instrument Driver is a library of LabVIEW VIs designed to assist users of the Shimmer2, Shimmer 2r and Shimmer3 in the development of Shimmer based applications in LabVIEW. More info can found on the LabVIEW web-page.
At Shimmer, we are currently not using any operating system for Shimmer3 firmware development. The use of TinyOS for Shimmer2r was, among other reasons, largely due to the availability of low level drivers, in particular, the AM radio stack. Currently, this is not a factor for Shimmer3 so we do not use any OS for our example apps. The benefits for developers are that there is no learning curve associated with an OS and, by coding at the 'bare metal' level, there is less abstraction and, so, less complication. Developers may choose to use any available MSP430 OS, if desired, such as FreeRTOS, TI SYS/BIOS, µV/OS-II, IAR PowerPac or any others; however, limited support will be available from Shimmer for such development.
Occasionally the USB UART drivers will fail to load. This condition typically happens when the Shimmer Dock has been unplugged and is often indicated by a solid UART activity LED (although this may not occur). The simple fix is to unplug the USB cable and retry. If this process fails to remedy the situation, please contact Shimmer support for assistance: http://dev.shimmersensing.com/support1/contact-support/wearable-sensing-support/
If the values are equal to '0' or do not make any sense then there is a possibility that the calibration procedure was performed incorrectly. It is suggested that you repeat the calibration procedure once again while taking note of the following points:
Once you have decided on your sensor coordinate axis ensure that you observe the correct orientations for each step of the calibration.
Ensure that the Shimmer you are calibrating is the Shimmer that is connected to the PC (Check the BT RADIO ID on the label at the bottom side of the Shimmer.).
Ensure that you hold the Shimmer static during the appropriate periods.
Make sure to perform each step of the calibration and make sure you are using the latest version of the LogAndStream firmware and 9DoF Calibration Application.
Check out our 'Shimmer3 Getting Started Video' (Shimmer3) Also refer to the corresponding section in the User Manual.
Please note that a Shimmer device may require a number of attempts to connect, because of the following reasons:
1. Paging Inquiry - When the Shimmer is not connected, the paging inquiry window on the BT radio defaults to 320ms (out of 2.56s) so the Shimmer is only 'listening' for a connection 12.5% of the time.
2. FHS (frequency hopping synchronization) - When a BT slave successfully connects or pairs with a BT master, they synchronize their frequency hopping pattern. If a master has not connected to a slave over a long period of time, then the frequency hopping pattern can get severely out of sync. Variations in clock drift across Shimmers means that some Shimmers will get out of sync more easily than others. Note: Once a connection is made the frequency pattern of the master and slave are once again synchronised.
1. Select the Refresh option listed in the COM Port drop down box on the GUI. If problem
persists go to step 2.
2. Verify the COM Port that your Shimmer is paired with, corresponds to the COM Port in the
drop down menu. This procedure is outlined in the Consensys Guide - "Getting Started wth Consensys" - which can be found on our documentaiton page
In the unlikely event that the application crashes and you can either wait for an Android prompt allowing you to close the application, or you can close the application manually via Settings → Application manager → MultiShimmerSync → Force Stop