Thank you!
I was getting this on my M5StickC-Plus, on the 10th/Oct/2022, with all the latest board/library updates.
I hope everyone else can find this thread!
For me the file I had to add those lines to was:
C:\Users[login name]\AppData\Local\Arduino15\packages\m5stack\hardware\esp32\2.0.5\boards.txt
Support have contacted me, it's an MCX connector!
The one on the LoRa module is female, so the plug you buy needs to be an MCX Male connector.
I've bought these converters for SMA plugs:
https://www.amazon.co.uk/gp/product/B012THC0FO
The MCX connector is exactly the same one as on most of the SDR USB sticks... https://www.amazon.co.uk/TenYua-Digital-Receiver-RTL2832U-R820T2
So if you already have a USB software defined radio hanging around, the rubbish little twig antenna can be cut off the cable, and it reused as a J antenna cable!
Thank you for this awesome tutorial.
I've got my copper wire on order, and am looking forward to putting it together. =D
Thanks to some brilliant recent inventions, there's now antenna analysers for $50, called "NanoVNA". You can use them to perfectly tune the J Pole antenna, so as much of the transmit power as possible leaves the antenna.
As my title!
Thank you everyone!
xx
https://shop.m5stack.com/products/atomu-esp32-development-kit-with-usb-a
It's the odd one out when everything else I've seen is a USB-C.
Do you think there was a certain use in mind to require this kind of plug?
@m5stack Any idea when that engineer will add I2C to the M5StickC Plus? I just added it to my own copy and it only took 15 minutes. It'd make a lot more M5StickC programs compatible with the Plus too!
I'm going through all my M5Stack purchases and making something for each of them.
My latest project is a 4 degrees of freedom (basically 4 servos) robot arm featuring some ultra tiny 1.7g hk-5320 servos and a bit of 3D printing that I'll use my M5StickC Plus and the C- Back Hat... the worlds smallest DIY robot arm!
In the mean time, I wanted to test some code out on an arm and I found the cheapest one was on banggood.... £15 all in, including the servos.
It doesn't come with a controller board - but that's ideal, as the M5Stick's going to be the controller!
A 4 DOF robot arm is interesting - it's movement can be broken down into 3 main parts:
Servos are evil, they take an angle as their mode of control. So the sticking point with MOST the simple controllers you see is that you have to move each servo at a time, angling the arm out, then angling it down to pick something up.
It'd be much easier to ask it to move to an x/y position away from the base of the arm.
With that in mind, if you want to write your own servo robot arm controller, I've included a function I found that given an X/Y position, provides the two servo angles for the "shoulder and elbow" part of the robot:
https://codepen.io/SarahC/pen/ExXMgJx
And here's the robot arm I found:
https://www.banggood.com/Small-Hammer-3D-Print-DIY-4DOF-RC-Robot-Arm-Kit-With-SG90-Servos-p-1451689.html
In BUGC.ino, there's an interesting line - "If add battery, need increase charge current".
It's brief! I take it to mean - that if I use the little li-ion battery that comes with the BUGC, I need to include this line that changes the charging current of the M5StickC?
I'm -guessing- that the battery in place also powers the M5StickC's internal battery charger?
Why am I increasing it!? Shouldn't I be decreasing the charge current to it doesn't drain the robots power?
What if I left it as whatever its default is?
void setup()
{
M5.begin();
BugC.Init();
M5.Lcd.setTextColor(TFT_GREEN);
M5.Lcd.setRotation(1);
M5.Lcd.drawCentreString("BUGC example", 120, 50, 4);
// if add battery, need increase charge current
M5.Axp.SetChargeCurrent(CURRENT_360MA);
}A year ago?
It looks to me like you have a duff RGB panel. Did you ever get it swapped?
Thank you both!
In the interests of experimentation... I just had to see what havoc using the Grove connector with the IR Unit would cause.
I found that if I don't actively access the IC2 components, and just treat them as standard IO pins, they don't get in the way of any data I'm getting.
I was able to demonstrate this really well with the IR Remote Control demo, using one Grove pin for the IR receiver, and turning the other Grove pin low to turn off the IR LED (which gets in the way of reception).
I was able to scan 3 different remote controls, and also produce their raw flashes on the LCD as a diagram!
For anyone that wants/needs to do this very un-recommended Grove useage:
/*
IRremoteESP8266: IRrecvDumpV3 - dump details of IR codes with IRrecv
An IR detector/demodulator must be connected to the input kRecvPin.
Copyright 2009 Ken Shirriff, http://arcfn.com
Copyright 2017-2019 David Conran
Example circuit diagram:
https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-receiving
Changes:
Version 1.2 October, 2020
- Enable easy setting of the decoding tolerance value.
Version 1.1 May, 2020
- Create DumpV3 from DumpV2
- Add OTA Base
Version 1.0 October, 2019
- Internationalisation (i18n) support.
- Stop displaying the legacy raw timing info.
Version 0.5 June, 2019
- Move A/C description to IRac.cpp.
Version 0.4 July, 2018
- Minor improvements and more A/C unit support.
Version 0.3 November, 2017
- Support for A/C decoding for some protocols.
Version 0.2 April, 2017
- Decode from a copy of the data so we can start capturing faster thus
reduce the likelihood of miscaptures.
Based on Ken Shirriff's IrsendDemo Version 0.1 July, 2009,
*/
// Allow over air update
// #define OTA_ENABLE true
//#include "BaseOTA.h"
#include <M5Stack.h>
//#include <Arduino.h>
#include <assert.h>
#include <IRrecv.h>
#include <IRremoteESP8266.h>
#include <IRac.h>
#include <IRtext.h>
#include <IRutils.h>
// M5Stack Core grey screen dimensions, and settings for the diagram display.
int dispWidth = 320;
int dispHeight = 240;
int stripNum = 0;
int stripsDownScreen = 6;
int stripHeight = dispHeight / stripsDownScreen;
// ==================== start of TUNEABLE PARAMETERS ====================
// An IR detector/demodulator is connected to GPIO pin 14
// e.g. D5 on a NodeMCU board.
// Note: GPIO 16 won't work on the ESP8266 as it does not have interrupts.
const uint16_t kRecvPin = 22; // Pin 22 on the M5Stack-Core-Grey.
// The Serial connection baud rate.
// i.e. Status message will be sent to the PC at this baud rate.
// Try to avoid slow speeds like 9600, as you will miss messages and
// cause other problems. 115200 (or faster) is recommended.
// NOTE: Make sure you set your Serial Monitor to the same speed.
const uint32_t kBaudRate = 115200;
// As this program is a special purpose capture/decoder, let us use a larger
// than normal buffer so we can handle Air Conditioner remote codes.
const uint16_t kCaptureBufferSize = 2048;
// kTimeout is the Nr. of milli-Seconds of no-more-data before we consider a
// message ended.
// This parameter is an interesting trade-off. The longer the timeout, the more
// complex a message it can capture. e.g. Some device protocols will send
// multiple message packets in quick succession, like Air Conditioner remotes.
// Air Coniditioner protocols often have a considerable gap (20-40+ms) between
// packets.
// The downside of a large timeout value is a lot of less complex protocols
// send multiple messages when the remote's button is held down. The gap between
// them is often also around 20+ms. This can result in the raw data be 2-3+
// times larger than needed as it has captured 2-3+ messages in a single
// capture. Setting a low timeout value can resolve this.
// So, choosing the best kTimeout value for your use particular case is
// quite nuanced. Good luck and happy hunting.
// NOTE: Don't exceed kMaxTimeoutMs. Typically 130ms.
/*
#if DECODE_AC
// Some A/C units have gaps in their protocols of ~40ms. e.g. Kelvinator
// A value this large may swallow repeats of some protocols
const uint8_t kTimeout = 50; //50
#else // DECODE_AC
// Suits most messages, while not swallowing many repeats.
const uint8_t kTimeout = 15; //15
#endif // DECODE_AC
*/
const uint8_t kTimeout = 50;
// Alternatives:
// const uint8_t kTimeout = 90;
// Suits messages with big gaps like XMP-1 & some aircon units, but can
// accidentally swallow repeated messages in the rawData[] output.
//
// const uint8_t kTimeout = kMaxTimeoutMs;
// This will set it to our currently allowed maximum.
// Values this high are problematic because it is roughly the typical boundary
// where most messages repeat.
// e.g. It will stop decoding a message and start sending it to serial at
// precisely the time when the next message is likely to be transmitted,
// and may miss it.
// Set the smallest sized "UNKNOWN" message packets we actually care about.
// This value helps reduce the false-positive detection rate of IR background
// noise as real messages. The chances of background IR noise getting detected
// as a message increases with the length of the kTimeout value. (See above)
// The downside of setting this message too large is you can miss some valid
// short messages for protocols that this library doesn't yet decode.
//
// Set higher if you get lots of random short UNKNOWN messages when nothing
// should be sending a message.
// Set lower if you are sure your setup is working, but it doesn't see messages
// from your device. (e.g. Other IR remotes work.)
// NOTE: Set this value very high to effectively turn off UNKNOWN detection.
const uint16_t kMinUnknownSize = 12;
// How much percentage lee way do we give to incoming signals in order to match
// it?
// e.g. +/- 25% (default) to an expected value of 500 would mean matching a
// value between 375 & 625 inclusive.
// Note: Default is 25(%). Going to a value >= 50(%) will cause some protocols
// to no longer match correctly. In normal situations you probably do not
// need to adjust this value. Typically that's when the library detects
// your remote's message some of the time, but not all of the time.
const uint8_t kTolerancePercentage = kTolerance; // kTolerance is normally 25%
// Legacy (No longer supported!)
//
// Change to `true` if you miss/need the old "Raw Timing[]" display.
#define LEGACY_TIMING_INFO false
// ==================== end of TUNEABLE PARAMETERS ====================
// Use turn on the save buffer feature for more complete capture coverage.
IRrecv irrecv(kRecvPin, kCaptureBufferSize, kTimeout, true);
decode_results results; // Somewhere to store the results
// This section of code runs only once at start-up.
void setup() {
// Setup the M5Core systems, and ready the screen.
M5.begin();
M5.Power.begin();
M5.Lcd.fillScreen(WHITE);
M5.Lcd.setTextColor(WHITE);
M5.Lcd.setTextSize(1);
M5.Lcd.setCursor(10, 10);
// Turn off the IR LED - otherwise it makes noise for the receiver.
pinMode(21, OUTPUT);
digitalWrite(21, LOW);
delay(100);
//OTAwifi(); // start default wifi (previously saved on the ESP) for OTA
#if defined(ESP8266)
Serial.begin(kBaudRate, SERIAL_8N1, SERIAL_TX_ONLY);
#else // ESP8266
Serial.begin(kBaudRate, SERIAL_8N1);
#endif // ESP8266
while (!Serial) // Wait for the serial connection to be establised.
delay(50);
// Perform a low level sanity checks that the compiler performs bit field
// packing as we expect and Endianness is as we expect.
assert(irutils::lowLevelSanityCheck() == 0);
Serial.printf("\n" D_STR_IRRECVDUMP_STARTUP "\n", kRecvPin);
//OTAinit(); // setup OTA handlers and show IP
#if DECODE_HASH
// Ignore messages with less than minimum on or off pulses.
irrecv.setUnknownThreshold(kMinUnknownSize);
#endif // DECODE_HASH
irrecv.setTolerance(kTolerancePercentage); // Override the default tolerance.
irrecv.enableIRIn(); // Start the receiver
}
// The repeating section of the code
void loop() {
// Check if the IR code has been received.
if (irrecv.decode(&results)) {
// Display a crude timestamp.
uint32_t now = millis();
Serial.printf(D_STR_TIMESTAMP " : %06u.%03u\n", now / 1000, now % 1000);
// Check if we got an IR message that was to big for our capture buffer.
if (results.overflow)
Serial.printf(D_WARN_BUFFERFULL "\n", kCaptureBufferSize);
// Display the library version the message was captured with.
Serial.println(D_STR_LIBRARY " : v" _IRREMOTEESP8266_VERSION_ "\n");
// Display the tolerance percentage if it has been change from the default.
if (kTolerancePercentage != kTolerance)
Serial.printf(D_STR_TOLERANCE " : %d%%\n", kTolerancePercentage);
// Display the basic output of what we found.
Serial.print(resultToHumanReadableBasic(&results));
// Display any extra A/C info if we have it.
String description = IRAcUtils::resultAcToString(&results);
if (description.length()) Serial.println(D_STR_MESGDESC ": " + description);
yield(); // Feed the WDT as the text output can take a while to print.
#if LEGACY_TIMING_INFO
// Output legacy RAW timing info of the result.
Serial.println(resultToTimingInfo(&results));
yield(); // Feed the WDT (again)
#endif // LEGACY_TIMING_INFO
// Output the results as source code
Serial.println(resultToSourceCode(&results));
// Draw the next strip containing the signal. Scale to fit the screen, and the length of the signal.
double timingTotal = 0;
int arrayLength = getCorrectedRawLength(&results);
uint16_t *timings = resultToRawArray(&results);
for (int i = 0; i < arrayLength; i++) {
timingTotal += timings[i];
}
int y = stripNum * stripHeight;
int currentTotal = 0;
double scaler = (double)dispWidth / (double)timingTotal;
uint16_t col = 1;
for (uint16_t i = 0; i < arrayLength - 1; i++) {
double timeWidth = ((double)timings[i] * scaler);
double timeX = (currentTotal * scaler);
currentTotal += timings[i];
M5.Lcd.fillRect((int)timeX, (int)y, (int)timeWidth, stripHeight - 2, col ? BLACK : WHITE);
col = 1 - col;
}
if (++stripNum == stripsDownScreen) stripNum = 0;
Serial.println(); // Blank line between entries
yield(); // Feed the WDT (again)
}
}Right now in August 2021, there's two types of M5Go bottom, M5Go, and M5Go2.
The M5Go2 remaps Port C's pins that are used on the Core2 for the PSRAM. This means that there's no unsoldering needed on the Core2 to use Port C, and the PSRAM now stays enabled! Yay!
(If you DID try using your M5Go (not M5Go2) on a Core2... you'd break PSRAM support. Core2 NEEDS a M5Go2.)
Here are the pin positions for Port A, Port B, and the Grove port, for the Core and Core 2:
Core (M5Go):
Port A (Red) : Pins SCL 22, SDA 21 : I2C, Supports digital and I2C mode,
Port B (Black) : Pins DAC 26, ADC 36 : DAC/ADC, Is generic IO
Port C (Blue) : Pins TX 16, RX 17 : Supports UART mode however outside of UIFlow the IO pins of the esp32 support various different modes.
Core 2 (M5Go2 bottom):
Port A (Red) : Pins SCL 32, SDA 33 : I2C, Supports digital and I2C mode,
Port B (Black) : Pins DAC 26, ADC 36 : DAC/ADC, Is generic IO
Port C (Blue) : Pins TXD2 14, RXD2 13 : Supports UART.
Just like the title says!
I've got a Core2 and the IR Sensor module. It's got a black connector for "Port B" on the Core2.
The Core Grey doesn't have a Port B, but it does have a red Grove!
Am I right in thinking the GND and +5 volts are the same pin positions on both?
Does that mean I could potential change out the two data pins for Port B, to be those of the Grove port?
I get that the Grove port and Port A and B have hardware support for some things like IC2, and erm... other control protocols. But for the IR Sensor, I believe I can use the pins in software, directly, just using "writeDigital" and "readDigital" ?
Am I about to blow up my Core Grey!?
It turned out to be my Ryzen Swift 3 USB drivers!
After updating them the problem resolved.
https://github.com/Sarah-C/M5Stack_Core2_ScreenBrightness
You might have noticed that setBrightness() doesn't do anything on the Core2, and ScreenBreath() seems dodgy. (See this: https://github.com/m5stack/M5Core2/issues/20 )
So while the complexities of the AXP192 registers are ironed out, I've created a function called core2Brightness(). It's not in a library, you just copy and paste it into your Arduino .ino sketch file.
core2Brightness() physically turns your backlight off at level 0, and increases the dimmable range of the backlight all the way down to "barely visible in absolute darkness".
It uses the absolute minimum discrete brightness levels enabled by the AXP192 library, so every value from 0 through 20 produces an observable change in brightness, unlike other available functions. =)
If you're a rebel, it can also increase the brightness range using the "turbo mode", but the official M5Stack view is not to do it, or for very short periods only else overheating and LED damage can occur. It's obvious damage, it'll void your warranty. You can't send it back if you overdrive it and it pops.
Help!
When I try uploading a sketch using Windows 10, and Arduino 1.8.15 to my Core2 I get the following:
"Connecting...................................____
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"
If I just select the "Serial Monitor" while the Core2's plugged in - when I reboot the Core 2, the Serial Monitor shows the bootup text, so the device is definitely connected AND communicating through all the USB ports I tried.
The Core Grey I bought earlier is working fine... it flashes every time without issue.
I've tried the following:
I've ran out of things to try!
Do I need a new Core2? How do I go about it? I don't want my money back - I love the touchscreen!