About to try and build a MobilECG-II

[GregoryLand]

I am about build one of these for personal use and monitoring of my heart. I was curious if the plans on the git are up to date and what trouble I might run into during this process. I will be getting a few boards spun and populated for myself to use and I would like to avoid having to rerun or bodge in things if I don't have to. Has a working prototype been built of the version in git?

[LukaBanovic]

@GregoryLand I'm interested in building one myself, have mobilecg got back to you through any channel?

[GregoryLand]

Hope haven't heard a peep.

[shriram-m]

Has anyone been able to successfully implement one on your own?

[LukaBanovic]

@Shriram-M no, this device as it is designed does not work.

At IRNAS we are working as a subcontractor with Glia team, developing open-source medical devices. Recently, we have started developing an open-source ECG and wanted to use MobilECG as a starting point. We have built one of their devices and spent two weeks debugging the hardware, without success. We have later on pursued to take fragments of MobilECG and started developing an our OS ECG from scratch. It is now being built and the designs checked, so the first prototype will be available here soon. Stay in the loop, once it's up there and you've successfully built one on your own, we'd be glad to hear your thoughts and comments.

[marcmathys]

Hi. We are very interested in the project and would like to participate/collaborate. Where does it stand now?

[shriram-m]

Hi. We are very interested in the project and would like to participate/collaborate. Where does it stand now?

I have successfully built the hardware. The firmware that is being provided doesn't work directly. I'm currently working with my team to develop the firmware and Android app from scratch. But the hardware design seems to be correct.

[RobertCsordas]

Hi all! Actually the software should work without any problems with the toolchain versions we used. With changes of GCC version, you may need to change the heap size, as newer versions tends to use more and more memory. If your software locks up and does nothing, that this is the most probable solution. As for the Android app, I modified it a month ago for another project, and it works. The only problem is that Google changed the build system in the new Android Studios (new: not as old as this project). If you copy over the source files to a new NDK project, and copy the relevant version of the config files, it will build and work as it should. For the hardware, I remember minor issues, like wrong footprint for an opamp, but nothing mayor. I remember soldering the Bluetooth module had a lot of issues resulting in short circuit at first few tries. We re-soldered it a few times until it worked. We never soldered the card reader/usb hub IC, so I don't know it that part is working or not. We built a total of 3 of them. If I will be able to find one, maybe I could tell you more about the hardware mods.

[GregoryLand]

Knowing this I would like to build one for personal use/ goofing around. Is anyone looking at doing a spin of boards in the short term that I could purchase a blank PCB to populate myself?

[GitterHubber]

@ xdever its good to see that you are still around monitoring the project. What kind of know bugs / issues did exist in MobilEcg. Is the current state of the project usable for a medical grade ECG?

[marcmathys]

How difficult would it be to replace the AD8232 with a Max30001 chip. This would allow cardiac values through the built in ICG with a very limited increase in cost. The chip also has peak detection and some other stuff built in.

[peterisza]

@marcmathys But there is no AD8232 in MobilECG.

[marcmathys]

Oh, sorry I confused the AD chip with the TI chip. The maxim chip also has more functionality than the TI chip. How hard and is there any interest in changing this? The device becomes much more robust.

[peterisza]

The Maxim chip is single-channel, the TI chip has 8 channels (for 12-lead ECG).

[marcmathys]

Yea, I guess that is the trade-off.

[shriram-m]

Hi all! Actually the software should work without any problems with the toolchain versions we used. With changes of GCC version, you may need to change the heap size, as newer versions tends to use more and more memory. If your software locks up and does nothing, that this is the most probable solution. As for the Android app, I modified it a month ago for another project, and it works. The only problem is that Google changed the build system in the new Android Studios (new: not as old as this project). If you copy over the source files to a new NDK project, and copy the relevant version of the config files, it will build and work as it should. For the hardware, I remember minor issues, like wrong footprint for an opamp, but nothing mayor. I remember soldering the Bluetooth module had a lot of issues resulting in short circuit at first few tries. We re-soldered it a few times until it worked. We never soldered the card reader/usb hub IC, so I don't know it that part is working or not. We built a total of 3 of them. If I will be able to find one, maybe I could tell you more about the hardware mods.

No. The software doesn't get locked up. The firmware when flashed as it is, will make the 2 LEDs (Red n Green LEDS on PB6 and PB7) toggle for 4 times. Then nothing happens. Hence, I don't think the problem is with the heap size..

[GregoryLand]

It looks like the LED flash is the second task running on the micro

void ledTaskCallback (OS::Task &task) {
UNUSED(task);

while(1){
    led1.on();
    led2.off();

    OS::sleep(500);

    led1.off();
    led2.on();

    OS::sleep(500);
}

In the main thread there seams to be a call to logger::panic

if (!ADS1298::instance().start())
    Logger::panic("Failed to initialize ADS1298.");

 void Logger::panic(const char *message){
    UNUSED(message);
    __disable_irq();
    for(;;);
}

It might be worth taking a look at these two sections.

uint8_t id = readReg(REG_ID);
if ((id >> 3) != 0x12 && (id >> 3)!= 0x1A){
    //Wrong device signature
    stop();
    return false;
}

nHardwareChannels = id & 0x07;
if (nHardwareChannels > 2){
    //Wrong channel number
    stop();
    return false;
}

Maybe something is failing in ADS1298 init? Hope this helps.

[RobertCsordas]

I think it is either a soldering problem with the BT module or with the ADS1298. Try putting a breakpoint in the panic function and checking the call stack. Check the power supplies. Check the ADS1298 data lines with a logic analyzer/oscilloscope to see if any activity is happening.

[RobertCsordas]

I finally found my prototype device. The only bodge on the board is marked with red. (the bodge near the power connector is because I ripped off a pad). I don't remember the details, I think it was wrong footprint for the opamp there.

[RobertCsordas]

Watch out, because it may be fixed on the online version of the PCB, so you might not need to do it, or you might need to jump different pins (I guess the input-output is jumped).

You might also experience programming problems in case you have a chinese ST-Link programmer like this: https://i.ebayimg.com/images/g/gsUAAOSwZ~hbCAJp/s-l1600.jpg. The source of the problem is that they wired wrong pin of the internal microcontroller to the reset pin on the board. The solution is to check the wiring on a random official STM32 devboard with on-board programmer, cut the trace of the reset pin in the device and attach it to the pin you see on the official devboard. Otherwise your device might not want to program, and you have to turn on-off a few times while trying to program it in order to work. This is very unreliable and annoying, so I recommend modifying the programmer before you start to play with it.

[shriram-m]

@xdever , thanks a lot for the info. I've checked the data lines of ADS1298 and I'm able to get data from the hardware with an external Bluetooth module. But the on-board Bluetooth module (which is soldered properly - verified with an X-ray scan) doesn't work and there seems to be some error with initialization of the stack.

It would be extremely helpful if you could share the details of the software and toolchain that you used to build the machine code so that I can eliminate the variables..

[RobertCsordas]

It was either a prebuilt Linaro GCC or an ARM gcc from Mac's homebrew. In either case it is just a plain ARM GCC (arm-none-eabi-gcc) with hardware floating point support. These are imporant, because the BT stack is closed source and provided as a library (libBluetopia_32_M4.fp_HW_FP.a). I think gcc version was 5, but it should not really matter. Check the data lines of the BT, if some data is going in/out from it. If the data is going in but not out, the BT module might still be bad. If no data is going in, or data is both going in and coming out, then it is a SW problem probably.

[RobertCsordas]

Actually there is a link in the readme.md to the tools we used (although not the exact version). They moved the site to https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads. Because this was developed in late 2015/early 2016 and I always use the newest software from everything possible, the oldest link on the page I linked should work for sure (5-2016-q1-update).

[RobertCsordas]

And please use the provided makefile to build it (software/firmware/makefile).

[shriram-m]

@xdever , thanks a ton for sharing the details !! I will certainly try them out..

[RobertCsordas]

Keep me updated if you find out what is the problem and I'll add it to the readme.

[shriram-m]

Sure..

[shriram-m]

I tried building the code using the older toolchain (5-2016-q1-update) on a 32-bit Linux system. The problem still persists. But I figured out that ADS1298 is initialised properly (as the LEDs do not stop toggling) but there's some error with initialisation of the stack on the BLE module. I shall try and debug the hardware further to figure out what exactly is causing the error..