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.

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.

It turned out to be my Ryzen Swift 3 USB drivers!

After updating them the problem resolved.

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!

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?

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.

https://www.youtube.com/watch?v=QJYeFpiqY8c

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!

@m5stack Thank you!

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:

1. 1 motor spins your arm around a half circle. (servos usually go 180 degrees max)
2. 1 motor controls the grasping clamp at the end.
3. The magic happens with the last 2 motors... they're just like your own shoulder and elbow. Imagine resting your shoulder on a desk, rotating your shoulder joint and moving your arm across the desk and bending your elbow means you can reach all parts of the desk surface.

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

Ohhhhhh.....

https://community.m5stack.com/topic/2625/m5stickcplus-doesn-t-program-correctly/3

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);
}