The AdvancedRecyclerView Library is incredible. It has support for so many niceties, it’s almost indispensable. Unfortunately, documentation is sparse.
I wrote a quick demo for the draggable and swipable functions of the library that may be perused below. I plan to add support for the expandable items in the future. So, if you happen to need some documentation for the library, click the link below.
Android’s SwipeRefreshLayout is pretty useful for internet based apps that need to notify a user when a pull to refresh action has occurred. However, if you have a complex view hierarchy that uses a FrameLayout to draw certain items over another, say for example a contextual toolbar, the circular ProgressBar drawn by the SwipeRefreshLayout is obscured and hidden from the user.
A way to fix this is to create a class that extends the SwipeRefreshLayout, and Override the OnTouchEvent. Once overridden, call on the superclass to make sure the widget performs as intended, keep the boolean it returns in a local variable, and handle the motion events which will in turn fire off an interface callback when certain conditions are met.
It’s not complicated when presented in code form. The extended class is shown in it’s entirety below
| package com.myfab5.mobile.myfab5.ui.helpers.customcomponents; | |
| import android.content.Context; | |
| import android.support.v4.view.MotionEventCompat; | |
| import android.support.v4.widget.SwipeRefreshLayout; | |
| import android.util.AttributeSet; | |
| import android.view.MotionEvent; | |
| /** | |
| * A class that lets an activity know when the SwipeRefreshLayout has | |
| * been triggered, and when all finger's are off the device. | |
| */ | |
| public class NotifyingSwipeRefreshLayout extends SwipeRefreshLayout { | |
| private OnSwipeListener swipeListener; | |
| public NotifyingSwipeRefreshLayout(Context context) { | |
| super(context); | |
| } | |
| public NotifyingSwipeRefreshLayout(Context context, AttributeSet attrs) { | |
| super(context, attrs); | |
| } | |
| @Override | |
| public boolean onTouchEvent(MotionEvent ev) { | |
| final boolean superClassResult = super.onTouchEvent(ev); | |
| final int action = MotionEventCompat.getActionMasked(ev); | |
| switch (action) { | |
| case MotionEvent.ACTION_MOVE: | |
| if (superClassResult) { // The widget has been engaged. | |
| swipeListener.onSwipe(); | |
| } | |
| break; | |
| case MotionEvent.ACTION_UP: | |
| case MotionEvent.ACTION_CANCEL: // All fingers are up | |
| swipeListener.onFingerUp(); | |
| break; | |
| } | |
| return superClassResult; | |
| } | |
| /** | |
| * Set the listener to be notified when a refresh is triggered via the swipe | |
| * gesture or all fingers are off. | |
| */ | |
| public void setOnSwipeListener(OnSwipeListener listener) { | |
| swipeListener = listener; | |
| } | |
| /** | |
| * Classes that wish to be notified when a swipe has occured or fingers are off | |
| * should implement this interface. | |
| */ | |
| public interface OnSwipeListener { | |
| void onSwipe(); | |
| void onFingerUp(); | |
| } | |
| } |
Recently I’ve needed to read the values of an i2c digital potentiometer for all 64 steps, using the Agilent e4980a precision LCR meter. The problem is, control of the LCR and logging of the data is typically implemented through LabVIEW, software I don’t know how to use, and I don’t have at my beck and call.
Fortunately, the LCR supports the USBTMC standard and there happens to be a Python library for USBTMC. The following Python script uses nested for loops to ask an Arduino Uno to increase the wiper position for a rheostat, and then triggers the LCR and records the impedance of the rheostat at 99 AC frequencies for all 64 steps.
Things needed:
USBTMC Python Library To control USBTMC devices
PyUSB For Python USB control
LiUSB 1.0 C USB Library
Your Python IDE of choice (I’m using PyDev)
PySerial To write and read from Arduino’s serial
Once you have that sorted, the Python script is straightforward.
from time import sleep
import usbtmc
import serial
lcr = usbtmc.Instrument(2391, 2313)
Arduino = serial.Serial(‘/dev/tty.usbmodem1421′, 38400, timeout=10)
for i in range(0, 4):
print()
for R1 in range(0, 64):
# Instruct Arduino to change rheostat wiper
Arduino.write(b‘1’)
sleep(0.1)
for f in range(0, 99):
lcr.write(“:TRIG:IMM”)
lcr.last_btag = 0
sleep(0.01)
data = lcr.ask(“FETC:IMP:FORM?”)
sleep(0.01)
print(str(R1) + “,” + str(f) + “,” + data)
The companion Arduino code is:
#include “Wire.h”
#include “AD5258.h” //Library for AD5258 functions (must be installed)#define SSR 11
#define indicator_LED 12
AD5258 digipot; // rheostat r1
uint8_t wiper = 0;void setup() {
Serial.begin(38400);
Wire.begin();pinMode(indicator_LED, OUTPUT);
digipot.begin(1); // Specify i2c address for digipot
Serial.println();
}void loop() {
if (Serial.available()) {
uint8_t ch = Serial.read();
uint8_t status;if (ch == ‘0’) {
digitalWrite(indicator_LED, LOW);
Serial.println(“Switch off.”);
}if (ch == ‘1’) {
if(wiper == 64) {
wiper = 0;
}
digitalWrite(indicator_LED, HIGH);
digipot.writeRDAC(wiper);
Serial.print(“Triggered. wiper is at “);
Serial.println(wiper);
wiper++;
}} // end if serial available
} // end main loop
It works a charm and makes experimentation so much easier and faster.
A demo sketch that carries Bosch’s BMA250 accelerometer data over BLE specifically for the TinyDuino BLE shield and accelerometer shield.
The sketch is available here: Sketch
An android app for it is available here: App
Note the app was designed for a more complex sketch, therefore all the functions in the app such as “Sample Rate” and “Frequency Sweep” will not be available. You can still export accelerometer data from the app to the phone’s SD Card however.
Have fun!
If you don’t happen to have an Android phone, or an Android phone that has BLE support and you still want to work with Analog Device’s AD5933, I’ve written an Arduino sketch that allows one to interface with the AD5933 through the serial monitor on a hosting PC.
The sketch is available here.
Have fun!
First post of the new year! I figured, I’d start with something interesting.
Over winter break, I went home to the lovely warmth of West Africa, and had an epiphany of sorts as to how to extract the resistive values for intracellular water (ICW), extracellular water (ECW) and the capacitive value for the cell membrane after performing a frequency sweep on biological tissue (or model circuit) of interest.
Arduino boards are awesome. Even more awesome is the fact that there’s so much documentation out there on using them.
A very popular timer interrupt library for Arduino is MsTimer2, which has a resolution of 1 millisecond. If your project requires more resolution however, you’re a bit out of luck. Fortunately, it’s rather easy to increase the resolution of the timer library with a few modifications.
Earlier today I tested the Z_BLE_3 sketch on an Arduino Mega using its hardware serial and the results were fantastic.
It just goes to show, you may have a pretty good software serial library, but it’s nowhere near as good as the real hardware serial.
The default Arduino SoftwareSerial library proved to be non-tolerant with simple libraries when used for BLE communication, even more so with fairly complex libraries on top of that.
We switched to Paul Stoffregen’s AltSoftSerial library and things have been great… till now. From the documentation:
Interrupt Latency Requirements
AltSoftSerial can withstand approximately 1 bit time of interrupt latency from other libraries or functions. Most libraries, HardwareSerial, and the millis() timekeeping interrupt are designed to minimize CPU time spend executing interrupts or accessing data with interrupts disabled.
However, some libraries may disable interrupts for longer than 1 bit time. If they do, AltSoftSerial will not work properly. If you discover erroneous results from AltSoftSerial, please try testing without other libraries.
SoftwareSerial would break with relatively low complexity I2C communication using Arduino’s Wire library, it proved impossible to use with the AD5933 library for similar reasons.
AltSoftSerial works very well in this regard, but as we begin to write multiple sampling rates and frequency sweeps that request timer interrupts and reset commands to the AD5933 more frequently, the time window for interrupts to be handled shrink considerably.
With the sketch BLE_Debug_Timer that just carries a psuedo sine signal, setting a sampling rate of 90 Hz is no issue. Z_BLE_3 however that has to measure and send impedance values, breaks at sampling rates over 80 Hz and completely garbles serial communication with AltSoftSerial library, you only need to look at Arduino’s serial monitor to see the gibberish it spouts and functions it calls that it really shouldn’t.
We therefore probably need to move to the Arduino Mega for development and use the multiple hardware serial port it provides for BLE communication.
All this of course is a working hypothesis, I will be testing my claims tomorrow in lab, but I’m fairly certain they’re right from past experience with SoftwareSerial and AltSoftSerial.
On we go again.
If your Android app has paired with your device before, and you update the Gatt structure of your BLE Slave / Peripheral, you will need to clear the cache Android side, else the Android app will continue to show the old Gatt structure.
To clear the cache, all you need to do is toggle Bluetooth on and off. With this done, the cache should be clear and your new Gatt structure will be picked up when you scan and connect to your device again.
Tunji's shenanigans 