Archive

Posts Tagged ‘stm32’

WizziKit is a DASH7, LoRa and Sigfox Wireless Sensor & Actuator Network Kit

September 13th, 2017 2 comments

Over the last few years, I’ve written several article about LoRaWAN, Cellular IoT, and Sigfox based long range low power IoT solutions. DASH7 is another LPWAN (Low Power Wide Area Network) standard that operates on the same 868 and 915 MHz ISM bands as LoRa and Sigfox, but has much lower power consumption, and the cost of a shorter range up to 500 meters, instead of the 5+km associated with LoRa or SigFox.

The DASH7 Alliance Protocol (D7A) is an Open Standard, and if you want more details you can download version 1.1 of the specifications on DASH7 Alliance website. I’m writing about DASH7 today thanks to an article on ST blog about Wizzilab’s Wizzikit, an evaluation kit and framework for DASH7 with a gateway, and several nodes that can also optionally support LoRaWAN and Sigfox protocols.

Click to Enlarge

The kit is comprised of the following items:

  • WizziGate GW2120 Ethernet/Wifi/Dash7 gateway – based on GL-iNet AR150 router –  with antenna for the selected band (868/915 MHz) and USB power cable.
  • 2x Nucleo-L432KC STM32 development board compatible with Arduino. mbed, and ST morpho
  • 2x D7A SH2050 Nucleo Shield with a multimode Murata Lora Module supporting LoRa, DASH7, and Sigfox, as well as four sensor chips: light sensor,  magnetometer & accelerometer, humidity and temperature sensor, and a pressure sensor.
  • 2x mini USB cable to power up and program the Nucleo boards

DA7 SH2050 Shield

You’ll also need to add you own USB power adapter for the gateway. The kit also comes with access to the company’s DASH7Board cloud service. The Wiki includes some information, including a quick start guide explaining how to register the gateway, and start loading the demo code using mbed. Since DASH7 is much more power efficient than LoRaWAN it can either be used to prolong battery life, or to send more frequent messages for example to control actuators. With LoRaWAN, downlink access can only be initiated by the end node, but DASH7 is bi-directional allowing for OTA firmware upgrades. The solution was showcased a few months ago at ST Techday with two demos: sending a message to a single node, and OTA code upgrade (actually picture upload) to multiple boards with a broadcast message.

Wizzilab’s Wizzikit is sold for 299.00 Euros with either 868 and 915 MHz band. Further details on be found on Wizzilab website.

Wio LTE GPS Tracker Board Comes with a 4G Modem, Supports Espruino Firmware (JavaScript Programming)

September 6th, 2017 6 comments

Seeed Studio launched Wio GPS tracker with a 2G GSM module a few months ago, and while it should work in some countries, others are phasing out 2G networks, and only support 3G or 4G. The company has now launched an update with Wio LTE board with the same form factor, and most of the same features except they replaced the 2G/Bluetooth/GNSS module with a 4G LTE/GNSS module, and Atmel SAMD21 ARM Cortex M0+ microcontroller by an STMicro STM32 ARM Cortex-M4F MCU.

Wio LTE board specifications:

  • MCU – STMicro STM32F405RG ARM Cortex M4F MCU @ 168 MHz with 1MB flash, 192+4KB SRAM
  • Storage – micro SD slot
  • Connectivity via Quectel EC21-A (America) module
    • LTE Cat.1 modem:
      • FDD LTE: B2/B4/B12 WCDMA: B2/B4/B5
      • AT Command: 3GPP TS27.007 and enhanced AT Commands
      • Data – LTE-FDD Max 10Mbps(DL) Max 5Mbps (UL)
      • NanoSIM card
      • 2x u.FL antenna connectors
    • GNSS – GPS/BeiDou/GLONASS/Galileo/QZSS with 1x u.FL GNSS antenna connector
  • Audio – 3.5mm audio jack with mic and stereo audio
  • Expansion – 6x Grove Connectors (2x Digital, 2x Analog, 1x UART, 1x I2C)
  • USB – 1x micro USB port for power and firmware update
  • Misc – RGB LED, LTE power button, MCU reset button
  • Power Supply – 5V via micro USB port, 2-pin JST 1.0 header for battery
  • Dimensions – 54.7mm x 48.2mm

When I reviewed Wio GPS Tracker, the instructions provided to use with the Arduino IDE did not work very well. So let’s hope they will come up with a better and up-to-date getting started guide for Wio LTE board in their Wiki. Alternatively, the new board also supports Espruino for JavaScript programming for the I/Os, micro SD card, 4G, SMS, and GPS, and shown in Espruino Wio LTE page.

Seeed Studio is now taking pre-order for Wio LTE US Version for $97.50 plus shipping. Quectel also has other EC21 modules like EC21-E (EMEA, Korea, Thailand, India), EC21-AUT (Australia), and others, so I’d expect Seeed Studio to also launch variants of Wio LTE board that work in other countries.

Linux 4.13 Release – Main Changes, ARM & MIPS Architectures

September 4th, 2017 6 comments

Linus Torvalds has just announced the release of Linux 4.13 and a kidney stone…:

So last week was actually somewhat eventful, but not enough to push me to delay 4.13.

Most of the changes since rc7 are actually networking fixes, the bulk of them to various drivers. With apologies to the authors of said patches, they don’t look all that interesting (which is definitely exactly what you want just before a release). Details in the appended shortlog.

Note that the shortlog below is obviously only since rc7 – the _full_4.13 log is much too big to post and nobody sane would read it. So if you’re interested in all the rest of it, get the git tree and limit the logs to the files you are interested in if you crave details.

No, the excitement was largely in the mmu notification layer, where we had a fairly last-minute regression and some discussion about the problem. Lots of kudos to Jérôme Glisse for jumping on it, and implementing the fix.

What’s nice to see is that the regression pointed out a nasty and not very well documented (or thought out) part of the mmu notifiers, and the fix not only fixed the problem, but did so by cleaning up and documenting what the right behavior should be, and furthermore did so by getting rid of the problematic notifier and actually removing almost two hundred lines in the process.

I love seeing those kinds of fixes. Better, smaller, code.

The other excitement this week was purely personal, consisting of seven hours of pure agony due to a kidney stone. I’m all good, but it sure _felt_ a lot longer than seven hours, and I don’t even want to imagine what it is for people that have had the experience drag out for longer. Ugh.

Anyway, on to actual 4.13 issues.

While we’ve had lots of changes all over (4.13 was not particularly big, but even a “solidly average” release is not exactly small), one very _small_ change merits some extra attention, because it’s one of those very rare changes where we change behavior due to security issues, and where people may need to be aware of that behavior change when upgrading.

This time it’s not really a kernel security issue, but a generic protocol security issue.

The change in question is simply changing the default cifs behavior: instead of defaulting to SMB 1.0 (which you really should not use: just google for “stop using SMB1” or similar), the default cifs mount now defaults to a rather more modern SMB 3.0.

Now, because you shouldn’t have been using SMB1 anyway, this shouldn’t affect anybody. But guess what? It almost certainly does affect some people, because they blithely continued using SMB1 without really thinking about it.

And you certainly _can_ continue to use SMB1, but due to the default change, now you need to be *aware* of it. You may need to add an explicit “vers=1.0” to your mount options in /etc/fstab or similar if you *really* want SMB1.

But if the new default of 3.0 doesn’t work (because you still use a pterodactyl as a windshield wiper), before you go all the way back to the bad old days and use that “vers=1.0”, you might want to try “vers=2.1”. Because let’s face it, SMB1 is just bad, bad, bad.

Anyway, most people won’t notice at all. And the ones that do notice can check their current situation (just look at the output of “mount” and see if you have any cifs things there), and you really should update from the default even if you are *not* upgrading kernels.

Ok, enough about that. It was literally a two-liner change top defaults – out of the million or so lines of the full 4.13 patch changing real code.

Go get the new kernel,

Linus

Two months ago, Linux 4.12 was released with initial support for AMD Radeon RX Vega GPU, BFQ (Budget Fair Queuing) and Kyber block I/O schedulers, AnalyzeBoot tool for the kernel, “hybrid consistency model” implementation for live kernel patching, but disabled the Open Sound System, and removed AVR32 support, among many other changes.

Some interesting changes in Linux 4.13 – mostly based on LWN 4.13 Merge Window part 1 & part 2 – include:

  • Support for non-blocking buffered I/O operations added at the block level, which should also improve asynchronous I/O support when used with buffered I/O.
  • AppArmor security module’s “domain labeling” code has been merged into the mainline. It was maintained by Ubuntu out of tree previously.
  • Kernel-based TLS implementation that should deliver better performance for HTTPS, and other protocol relying on TLS.
  • CIFS/SAMBA now defaults to v3.0 instead of v1.0 due to security issues
  • File System Changes – EXT-4: support for to ~2 billion files per directory with largedir option, extended attributes up to 64KB, new deduplication feature; f2fs: supports disk quotas; overlayfs union: new “index directory” feature that makes copy-up operations work without breaking hard links.

Changes specific to ARM include:

  • Rockchip:
    • Added support for RV1108 SoC for camera applications
    • Rockchip IOMMU driver is now available on ARM64
    • PCIe – configure Rockchip MPS and reorganize + use normal register bank
    • Clock driver for Rockchip RK3128 SoC
    • Rockchip pinctrl driver now supports iomux-route switching for RK3228, RK3328 and RK3399
    • Sound driver – Support for Rockchip PDM controllers
    • Device tree
      • Added RK3399-Firefly SBC
      • Added ARM Mali GPU
      • Added cru
      • Added sdmmc, sdio, emmc nodes for Rockchip RK3328
  • Amlogic
    • Updated CEC EE clock support
    • Enabled clock controller for 32-bit Meson8
    • Device tree changes
      • Meson UARTs
      • new SPI controller driver
      • HDMI & CVBS for multiple boards
      • new pinctrl pins for SPI, HDMI CEC, PWM
      • Ethernet Link and Activity LEDs pin nodes
      • SAR ADC support for Meson8 & Meson8b
    • Defconfig changes – Meson SPICC enabled as module; IR core, decoders and Meson IR device enabled;
    • New boards & devices: NanoPi K2, Libre Computer SBC, R-Box Pro
  • Samsung
    • Clock driver updated for Samsung Exynos 5420 audio clocks, and converted code to clk_hw registration APIs
    • Pinctrl drivers split per ARMv7 and ARMv8 since there’s no need to compile everything on each of them
    • ARM DT updates:
      • Add HDMI CEC to Exynos5 SoCs + needed property for CEC on Odroid U3
      • Fix reset GPIO polarity on Rinato
      • Minor cleanups and readability improvements.
    • ARM64 DT updates:
      • Remove unneeded TE interrupt gpio property
    • Defconfig changes – Some cleanups, enabled Exynos PRNG along with user-space crypto API.
  • Qualcomm
    • Clock & pinctrl drivers for Qualcomm IPQ8074
    • Add debug UART addresses for IPQ4019
    • Improve QCOM SMSM error handling
    • Defconfig
      • Enable HWSPINLOCK & RPMSG_QCOM_SMD to get some Qualcomm boards to work out of the box/again
      • Enable IPQ4019 clock and pinctrl
    • Mailbox – New controller driver for Qualcomm’s APCS IPC
    • RPMsg – Qualcomm GLINK protocol driver and DeviceTree-based modalias support, as well as a number of smaller fixes
    • Qualcomm Device Tree Changes
      • Fix IPQ4019 i2c0 node
      •  Add GSBI7 on IPQ8064
      • Add misc APQ8060 devices
      • Fixup USB related devices on APQ8064 and MSM8974
    • Qualcomm ARM64 Updates for v4.12
      • Fix APQ8016 SBC WLAN LED
      • Add MSM8996 CPU node
      • Add MSM8992 SMEM and fixed regulator
      • Fixup MSM8916 USB support
  • Mediatek
    • CPU clks for Mediatek MT8173/MT2701/MT7623 SoCs
    • Pinctrl – Serious code size cut for MT7623
    • Mediatek “scpsys” system controller support for MT6797
    • Device tree
      • Added support for MT6797 (Helio X20) mobile SoC and evaluation board
      • Extended MT7623 support significantly
      • Added MT2701 i2c device & JPEG decoder nodes
  • Other new ARM hardware platforms and SoCs:
    • STM32 – stm32h743-disco, stm32f746-disco, and stm32f769-disco boards; Drivers for digital audio interfaces, S/PDIF receiver, digital camera interfaces, HDMI CEC, watchdog timer
    • NXP – Gateworks Ventana GW5600 SBC;  Technexion Pico i.MX7D board; i.MX5/6 image processing units & camera sensor interfaces
    • Realtek – Initial support for Realtek RTD1295 SoC and Zidoo X9S set-top-box
    • Actions Semi – Initial support for Actions Semi S900 / S500, and corresponding LeMaker Guitar & Bubblegum-96 SBCs
    • Renesas – Salvator-XS and H3ULCB automotive development systems; GR-Peach board, iWave G20D-Q7 System-on-Module plus
    • Socionext- Support for Uniphier board support for LD11-global and LD20-global
    • Broadcom – Stingray communication processor and two reference boards;
    • Marvell – Linksys WRT3200ACM router
    • Texas Instruments – BeagleBone Blue
    • Microchip / Atmel – MMU-less ARM Cortex-M7 SoCs (SAME70/V71/S70/V70)

Some of the changes specific to MIPS include:

  • Boston platform support – Document DT bindings; Add CLK driver for board clocks
  • CM – Avoid per-core locking with CM3 & higher; WARN on attempt to lock invalid VP, not BUG
  • CPS – Select CONFIG_SYS_SUPPORTS_SCHED_SMT for MIPSr6; Prevent multi-core with dcache aliasing; Handle cores not powering down more gracefully; Handle spurious VP starts more gracefully
  • DSP – Add lwx & lhx missaligned access support
  • eBPF – Add MIPS support along with many supporting change to add the required infrastructure
  • Generic arch code:
    • Misc sysmips MIPS_ATOMIC_SET fixes
    • Drop duplicate HAVE_SYSCALL_TRACEPOINTS
    • Negate error syscall return in trace
    • Correct forced syscall errors
    • Traced negative syscalls should return -ENOSYS
    • Allow samples/bpf/tracex5 to access syscall arguments for sane
      traces
    • Cleanup from old Kconfig options in defconfigs
    • Fix PREF instruction usage by memcpy for MIPS R6
    • Fix various special cases in the FPU eulation
    • Fix some special cases in MIPS16e2 support
    • Fix MIPS I ISA /proc/cpuinfo reporting
    • Sort MIPS Kconfig alphabetically
    • Fix minimum alignment requirement of IRQ stack as required by ABI / GCC
    • Fix special cases in the module loader
    • Perform post-DMA cache flushes on systems with MAARs
    • Probe the I6500 CPU
    • Cleanup cmpxchg and add support for 1 and 2 byte operations
    • Use queued read/write locks (qrwlock)
    • Use queued spinlocks (qspinlock)
    • Add CPU shared FTLB feature detection
    • Handle tlbex-tlbp race condition
    • Allow storing pgd in C0_CONTEXT for MIPSr6
    • Use current_cpu_type() in m4kc_tlbp_war()
    • Support Boston in the generic kernel
  • Generic platform:
    • yamon-dt: Pull YAMON DT shim code out of SEAD-3 board;  Support > 256MB of RAM;  Use serial* rather than uart* aliases
    • Abstract FDT fixup application
    • Set RTC_ALWAYS_BCD to 0
    • Add a MAINTAINERS entry
  • core kernel – qspinlock.c: include linux/prefetch.h
  • Add support for Loongson 3
  • Perf – Add I6500 support
  • SEAD-3 – Remove GIC timer from DT; set interrupt-parent per-device, not at root node; fix GIC interrupt specifiers
  • SMP – Skip IPI setup if we only have a single CPU
  • VDSO – Make comment match reality; improvements to time code in VDSO”
  • Various fixes:
    • compressed boot: Ignore a generated .c file
    • VDSO: Fix a register clobber list
    • DECstation: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression
    • Octeon: Fix recent cleanups that cleaned away a bit too much thus breaking the arch side of the EDAC and USB drivers.
    • uasm: Fix duplicate const in “const struct foo const bar[]” which GCC 7.1 no longer accepts.
    • Fix race on setting and getting cpu_online_mask
    • Fix preemption issue. To do so cleanly introduce macro to get the size of L3 cache line.
    • Revert include cleanup that sometimes results in build error
    • MicroMIPS uses bit 0 of the PC to indicate microMIPS mode. Make sure this bit is set for kernel entry as well.
    • Prevent configuring the kernel for both microMIPS and MT. There are no such CPUs currently and thus the combination is unsupported and results in build errors.
    • ralink: mt7620: Add missing header

You can read the full Linux 4.13 changelog – with comments only – generated using git log v4.12..v4.13 --stat for the full details, and eventually kernelnewsbies’s Linux 4.13 changelog will be updated with an extensive list of chances.

Husarion CORE2 STM32 Board for Robotics Projects Works with ESP32, Raspberry Pi 3, or ASUS Tinkerboard

June 30th, 2017 No comments

Husarion CORE2 is a board designed to make robotics projects simpler and faster to complete with pre-configured software and online management. Projects can start using LEGOs, before moving to 3D printed or laser-cut version of the mechanical parts without having to spend too much time on the electronics and software part of the project.

CORE2 and CORE2-ROS Boards – Click to Enlarge

Two versions of the board are available: CORE2 combining STM32 MCU with ESP32 WiFI & Bluetooth module, and CORE2-ROS with STM32 instead coupled to a Raspberry Pi 3 or ASUS Tinkerboard running ROS (Robot Operating System). Both solutions share most of the same specifications:

  • MCU -STMicro STM32F4 ARM CORTEX-M4 MCU @ 168 MHz with 192 kB RAM, 1 MB Flash
  • External Storage – 1x micro SD slot
  • USB – 1x USB 2.0 host port with 1A charging capability; 1x micro USB port for debugging and programming via FTDI chip
  • Expansion Headers
    • hRPi expansion header for
      • CORE2-ROS –  a single board computer Raspberry Pi 3 or ASUS Tinker Board
      • CORE2 – an ESP32 based Wi-Fi module
    • 2x motor headers (hMot) with
      • 4x DC motor outputs with built-in H-bridges
      • 4x quadrature encoder inputs 1 A cont./ 2 A max. current per output (2 A/4 A current when paralleled)
    • 6x servo ports with selectable supply voltage (5 / 6 / 7.4 / 8.6 V) 3 A cont./4.5 A max. current for all servos together
    • 6x 6-pin hSens sensor ports with GPIOs, ADC/ext. interrupt, I2C/UART, 5 V out
    • 1x hExt extension port with 12x GPIO, 7x ADC, SPI, I2C, UART, 2 x external interrupts
    • 1x CAN interface with onboard transceiver
  • Debugging – DBG SWD (Serial Wire Debug) STM32F4 debug port; micro USB port for serial console
  • Misc – 5x LEDs, 2x buttons
  • Power Supply – 6 to 16V DC with built-in overcurrent, overvoltage, and reverse polarity protection
  • Dimensions – 94 x 85 mm

On the software side, Husarion provide a set of open source libraries for robots as part of their hFramework, using DMA channels and interrupts internally to handle communication interfaces. The company has also prepared tutorials dealing with ROS introduction, creating nodes, simple kinematics for mobile robot, visual object recognition, running ROS on multiple machines, and SLAM navigation. CORE2 board can also be programming using the Arduino IDE, and finally Husarion Cloud allows you to securely create a web user interface to control the robot, and even program the robot firmware from a web browser.

That means you can program your robot using either the Web IDE, or offline with an SDK plus Visual Studio Code and the Husarion extension. The development work flow is summarized above.

CORE2 boards can be used for a variety of projects such as robotic arms, telepresense robots, 3D printers, education robots, drones, exoskeletons, and so on. If you want to learn about robots, but don’t have LEGO Mindstorms and don’t feel comfortable making your own mechanical parts yet, ROSbot might be a good way to start with CORE2-ROS board, LiDAR, a camera, four DC motors with encoders, an orientation sensor (MPU9250), four distance sensors, a Li-Ion battery (3 x 18650 batteries) and a charger, as well as aluminum mechanics. It also happens to be the platform they use for their tutorials.

ROSbot

You’ll find all those items, and some extra add-on boards, on the CrowdSupply campaign, starting at $89 for CORE2 board with ESP32 module, $99 for CORE2-ROS board without SBC, and going up to $1,290 for the complete ROSbot with ASUS Tinker Board. Shipping is free to the US, and $8 to $20 depending on the selected rewards, with delivery scheduled for September 2017, except for ROSbot that’s planned for mid-October 2017.

MXCHIP AZ3166 IoT Developer Kit is Designed to Work with Microsoft Azure

June 25th, 2017 3 comments

MXCHIP is a Shanghai based company designing and manufacturing WiFi IoT modules such as EMW3165, which has now made a development board based on their EMW3166 STM32+ Cypress module – called MXChip AZ3166 – specifically designed for Microsoft Azure cloud computing platform.

Click to Enlarge

MXChip AZ3166 board specifications:

  • Wireless Module – EMW3166 WiFi module with STM32F412 ARM Cortex M4F MCU @ 100 MHz with 256KB SRAM,1MB+2MB SPI Flash, Cypress BCM43362 WiFi chip
  • Display – 128×64 OLED display
  • Audio – Audio codec, built-in microphone, and 3.5mm heaphone jack
  • Sensors – Motion sensor,  magnetometer, atmospheric pressure sensor,  temperature and humidity sensor
  • Expansion – Finger extension interface with 25 external I/O pins including GPIOs, I2C, I2S, UART, ADC, Reset, 3.3V, and GND
  • Debugging – DAP Link emulator
  • USB – 1x Micro USB port for power, programming, debugging
  • Misc – 2x user buttons;  1x RGB light; 3x working status indicator; IR emitter; Security encryption chip
  • Power Supply – 3.3V DC, maximum current 1.5A; 5V via micro USB port

The AZ3166 board is Arduino compatible can be used for prototyping IoT and smart device solutions using Visual Studio Code with Arduino Extension. Applications can  integrates with various services like Azure IoT Hub, Logic App and Cognitive Services. You’ll find more technical details on Microsoft’s Azure IoT Devkit and MXCHIP AZ3166 pages.

Visual Studio Code with Arduino Extension – Click to Enlarge

The board is not for sale yet, but you could get a preview board for free, if you can meet Microsoft’s “select criteria”.

Thanks to Freire for the tip.

STMicro Unveils STM32L4 Discovery Kit for IoT with WiFi, BLE, NFC, Sub-GHz RF, and Plenty of Sensors

May 29th, 2017 3 comments

STMicro has recently introduced B-L475E-IOT01A Discovery kit powered by STM32L4 Cortex-M4 and targeting IoT nodes with a choice of connectivity options including WiFi, Bluetooth LE, NFC, and sub-GHZ RF at 868 or 915 MHz, as well as a long list of various environmental sensors.

Click to Enlarge

B-L475E-IOT01A Discovery kit key features and specifications:

  • MCU – STM32L4 Series MCU based on ARM Cortex -M4 core with 1 MB Flash memory, 128 KB SRAM
  • Storage – 64 Mbit (8MB)  Quad-SPI Flash memory (Macronix)
  • Connectivity
    • Bluetooth 4.1 LE module (SPBTLE-RF)
    • Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915)
    • Wi-Fi module based on Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
    • Dynamic NFC tag based on M24SR with its printed NFC antenna
  • Sensors
    • 2x digital omni-directional microphones (MP34DT01)
    • Capacitive digital sensor for relative humidity and temperature (HTS221)
    • 3-axis magnetometer (LIS3MDL)
    • 3D accelerometer and 3D gyroscope (LSM6DSL)
    • 260-1260 hPa absolute digital output barometer (LPS22HB)
    • Time-of-Flight and gesture-detection sensor (VL53L0X)
  • USB – 1x micro USB OTG port (Full speed)
  • Expansion – Arduino UNO V3 headers, PMOD header
  • Debugging – On-board ST-LINK/V2-1 debugger/programmer with USB re-enumeration capability: mass storage, virtual COM port and debug port
  • Misc – 2 push-buttons (user and reset)
  • Power Supply – 5V via ST LINK USB VBUS or external sources

The board supports ARM mbed online compiler, but can also be programmed using IDEs such as IAR, Keil, and GCC-based IDEs. STMicro also provides HAL libraries and code samples as part of the STM32Cube Package, as well as X-CUBE-AWS expansion software to connect to the Amazon Web Services (AWS) IoT platform.

You’ll find documentation, hardware design files, software, and tools on  the product page, where you’ll also be able to purchase the board for $51.94 with either a 868 or 915 MHz RF module.

Particle Asset Tracker Kit v2 2G/3G GPS Location Tracker Supports Grove Modules

April 13th, 2017 No comments

Particle, the maker of IoT boards such as Electron 2G/3G module, has launched it second Asset Tracker Kit – based on Electron – with a smaller case, improved GPS performance, satellite support for GPS, GLONASS, Galileo & BeiDou, and compatibility with Seeed Studio Grove modules.

Click to Enlarge

Asset Tracker Kit v2 hardware specifications:

  • MCU – STMciro STM32F205 ARM Cortex M3 micro-controller @ @ 120 MHz with  1MB Flash, 128K RAM
  • Cellular Connectivity – U-Blox SARA U-series (3G) or G-series (2G) modem + NanoSIM card slot + u.FL connector for Antenna
  • Location
    • 72-channel u-bloxM8 engine with support for GPS/QZSS L1 C/A, GLONASS L10F, BeiDou B1I, Galileo E1B/C, SBAS L1 C/A: WAAS, EGNOS, MSAS, GAGAN
    • Update rates: Single GNSS: up to 18 Hz, 2 Concurrent GNSS: up to 10 Hz
    • Position accuracy of 2.5 m, sensitivity of -167 dBm
    • Acquisition times: Cold starts: 26s, Aided starts: 2s, Reacquisition: 1s
    • On board ceramic GPS antenna with LNA and bandpass filter with ability to switch to external active antenna
  • Expansion
    • 2x 18-pin header with  28 GPIOs (D0-D13, A0-A13), TX/RX, 2 GNDs, VIN, VBAT, WKP, 3V3, RST
    • 2x quick connect grove sensor ports
  • Sensor – Built in 3 axis IMU
  • Battery – 2,000 mAh LiPo battery
  • Dimensions –  board: 10.3 cm x 3.6 cm x 0.76 cm (1.27 cm including headers)
  • Operating temperature of –40° C to 85° C

Particle Asset Tracker Kit v2 comes with Electron board with either 2G or 3G connectivity, the “Asset Tracker Shield” PCB with GPS, the battery, antennas for GPS and cellular, a weatherproof case, a USB cable, a breadboard, a pinout reference card, and a Particle SIM card with 3 months of Particle’s 1MB monthly data plan. After three months, the plan cost $2.99 per month for up to 1MB data (equivalent to thousands of message), and $0.99 for each extra MegaBytes. There’s no contract and the plan can be stopped anytime.  The company also provides an Arduino Library for the asset tracker with examples for GPS, accelerometer, and wakonmove, as well as access to Particle Cloud to store and analyze the data.

There are three models of the kit for sale, Asset Tracker 2G for $109, as well as Asset Tracker 3G (America/Australia) and Asset Tracker 3G (Europe/Asia/Africa) both going for $129. Particles kits will provide much more flexibility than the 3G + GPS tracker kits available on Aliexpress for $70 and up, and should be much easier to get started with then rolling your own with Orange Pi-2G IoT board, a cheap GPS modules such as NavSpark mini, plus battery and case.

Secure IoT Connectivity with NodeMCU ESP8266 Board, ATECC508A Crypto Chip, Mongoose OS, and AWS IoT

March 7th, 2017 16 comments

There are many examples of Internet of Things projects, but more often than not the implementation is not secure, either because the device is exposed to the Internet with minimum or no security (worst case), or a gateway (hopefully) provides secure connection to the Internet, but the communication between sensor nodes and the gateway in the local network is not secure, due to memory limitation of the nodes, for example it might be challenging to implement security on ESP8266. Mongoose OS is an open source operating system for the Internet of Things developed by Cesanta working on ESP32, ESP8266, STM32, and TI CC3200, and the developers have demonstrated a secure solution with Mongoose OS running on ESP8266 connecting over a TLS connection to AWS IoT (Amazon Web Service IoT) and using TLS credentials stored in Microchip ATECC508A CryptoAuthentication Device.

NodeMCU with ATCRYPTOAUTH-XPRO (Left) or barebone ATECC508A (Right)

The addition of ATECC508 chip either using “XplainedPro extension board for crypto products” (ATCRYPTOAUTH-XPRO) or ATECC508A chip itself, is to avoid storing private TLS credentials in NodeMCU’s flash memory, as anybody with physical access to the device could steal private keys and get access to the cloud. ATECC508A is connected via the I2C interface of the target board.

So I guess the crypto chip truly makes sense if you have sensor nodes on the field with information important enough that third parties may be interested in getting access to your sensor to try read your private key from ESP8266’s flash. It costs less than $1, so you may consider it anyway, although you can still get a secure TLS connection between NodeMCU and AWS IoT without it, but it adds another level of security.

Once you are done with the hardware connections, you’ll need to install Mongoose OS on the board, and follow the MQTT + AWS IoT tutorial to get started. Nothing complicated need to be done to leverage the crypto chip, as the command mgos aws-iot-setup should automatically detect ATECC508A chip and use it.