Ezb V4 Custom Firmware V2



Hello everyone,

I would like to share the new custom firmware available for EZB 4.

Currently i'm beta testing the firmware fixing and polishing the code.

I'm still open for ideas, please comment.

  1. Initial screen:

User-inserted image

  1. Access point configuration:

User-inserted image

  1. Client/Station mode configuration:

User-inserted image

  1. HOST/EZB configuration:

User-inserted image

  1. Ports Configuration:

    User-inserted image

  2. Tools

Working in progress

I will describe in another post the new features.

By — Last update


Upgrade to ARC Pro

Discover the limitless potential of robot programming with Synthiam ARC Pro – where innovation and creativity meet seamlessly.


You are re-writing the firmware on the EZ-B? Wow! Any reason why? Are your re-writes of the firmware still compatible with ARC?


New features

  1. MACADDRESS configuration once you push a new firmware, the mac address is wiped, to avoid going to the code and change the macaddress, compile & upload, is possible to assign a new macaddress.

  2. network HOSTNAME the hostname will allow identifying the EZB in a network by name, or when looking the router networking devices.

  3. Change EZB & Camera TCP Ports

  4. Disable the Welcome Message, useful when working or playing after hours:)

  5. Broadcast EZB information I found a new window in ARC (Listening), then i went to check the desktop ports and i found a UDP port open, with some lucky and persistence and brute force (broadcasting multiple strings) i found the purpose, the feature allows the ARC to identify all the EZBs connected in the network a picture will help:

User-inserted image

Client configuration:

  1. Static IP settings
  2. Reconnect settings, how many times and the interval between each attempt, useful if you suffer from random wifi disconnections.

AP configuration:

  1. DNS name nothing special

Overview page: BSSID (AP MACADDRESS) RSSI Level (good to check if the wifi signal is good)


Regarding the PORTS option:

Allows per port startup initialization, this can help:

  1. servos jerking when EZB is switch on
  2. immediately initialize digital ports e.g. (HB25 motor controller requires low value in the first seconds otherwise enters in programming mode)


Yes the idea is to keep everything "kosher", the ARC is not affected.


I'm confused (it's Friday), you have a new IOT board already or you have hacked the current one? I thought hacking the current board was discouraged and Canadian Mounties would come nock on your door? ;)


This is really hacking the WiFi chip, not the EZ-B brain, and it is encouraged. See the link I provided. DJ gave instructions and an updated firmware (that btw fixes the DHCP problem from first generation boards) and makes several suggestions for possible hacks, some of which PTP included, and some he came up with himself (like adding the address broadcast function that will be part of the v4 x/2)



I would have shared the broadcast protocol if you still need it:)


Alan, thank you for the break down. That makes perfect sense. :)



Thanks, regarding the broadcast protocol does include the camera port ? I tried different combinations and no success.

another question for you or Jeremie:

As you know when the PIC32 lockups (i2c or other conditions) the red led is on.

  1. does exist a byte cmd sequence to restart the PIC32 ?

  2. Is the PIC32 MCLR pin available in the PCB ?

  3. there two pins x1 x2, are those clock pins ?

i would like to build a firmware option to reset the PIC32.

If no byte sequence, and the PIC32 MCLR pin is available i can connect to one of the WF121 digital ports.


Ports configuration is a great feature!


Sorry @PTP I didn't see this post until today.

It's actually when the STM32 on main board locks up that the red LED stays lit.

  1. Sorry I don't know but @DJ might.

  2. Yes, MCLR is broken out to the first pin of the programming header

  3. X1 and X2 are "extra" pins made available from the STM32. There were broken out for future projects but haven't been utilized yet.


The PIC32 is the wifi module that you are programming, and it does not lock up with the red led.

The red led is connected to the bottom board STM32. When the red led comes on from incorrect i2c communication, there is no software recovery. You will need to reset the power on the stm32, as it cannot be done via software.

As for the ezb broadcast, here is the protocol...

UDP Port: 4242

"EZ-B v4.x||%s||%s||%u",
  name of ezb (i.e. "My EZB")
  ip address  (i.e. "")
  port        (i.e. "23")
  name of ezb (i.e. "My EZB")
  ip address  (i.e. "")
  port        (i.e. "24")

Transmit those packets every 3-6 seconds to (0xffffffff). For udp broadcast, be sure to use socket option SO_BROADCAST


@DJ, Jeremie: Thanks for coming back to the thread, i know you have a lot in your plates.

I wrote it incorrectly (PIC32) i wanted to write ARM:)


Arm board:

The NRST pin (7) is not accessible, 1)i see a capacitor C13 connected to GND and NRST 2)i presume the NRST is connected to the VCC, but i can't guess if there is a resistor between VCC and NRST ?

If there is a resistor, i can safely pull down to do a reset. The idea is to restart the ARM when is in lock mode.


Just updated my (2) V4's tonight to fix the wifi glitch. Would love to give this a whirl when it's available.




Yes C13 is the only connection to NRST. There is a weak 40kohm internal pullup resistor that ties it high.


Any word on release date? Need another beta tester? ;-)


Hello Everyone,

I've been busy improving and testing the Firmware, but to avoid delaying more.

I'm releasing the binary here:


I've plans to create a github repository similar to the V1 version plus some posts about the development challenges.

it will take extra time meanwhile i would love to get some feedback from the community.

Combining the last hardware manufacturer firmware (Blue Giga) plus optimizing the BGS code, i believe the new firmware is more stable and reliable.

I've introduced new features (next post) so i cannot guarantee is bug free:)


I've a friend that runs a robotic classes & extra school activities (no EZR hardware yet), so i lend him a few ezbs and ez-bits to introduce EZR to his students.

Some of his teenager students decided to "sabotage" other students rebooting or changing the servos positions plus adding other devices to the school network (password is open in the client page) .

They had some fun trolling around.

To avoid those issues I decided to improve the EZB http server security. To access pages: Access Point, Client, Ezb, Ports, Security you will need to authenticate first:

User-inserted image

the default password is password.

you can then later change via Security page:

User-inserted image

Also the Client & AP security keys are masked "*" just in case you browsing around with someone looking:

User-inserted image

The initial page is always accessible without authentication:

User-inserted image

although the reboot button is only available if you are authenticated.

If you reboot the EZB, or someone else authenticates, your session is gone, and the browser will redirect you to the login page when you try to access the secured pages.

Thumb rule: Only one user authenticated on the EZB HTTP Server.

I hope this will keep away the middle school bullies.


more changes:

  1. Overview page shows the Client Remote IPs connected to the EZB and the Camera.

I've plans to log these events to a server, that will help to avoid students messing other EZBs.

  1. When in client mode, EZB synchronizes the time with a time server only once after the connection is established.

Although the hardware and the firmware supports a RTC (Real Time Clock) the EZR pcb does not have a required 32kHz crystal.

@Jeremie i know the PCB space is always a constrain, but if please next time think about hackers and add extra connections pins/soldering points for the remain IO pins, add-ons etc.

So without a hardware RTC, the clock is software based... expect to loose some seconds.

One possible solution is to keep updating the clock

I have more ideas and some of them requires a clock, for example performing some actions based on time/day of week.

It was a really fun challenge, but the EZR future is with another chip.

I have other projects between work and family, the free time is not enough to explore all the ideas.


Hi ptp,

Loaded the firmware onto one of my V4's today.

So far everything is looking good. Great work on this!

I'll let you know if I run into any glitches.


South Africa

Absolutely fantabulous work @ptp. I wish I had a programmer to load this firmware!

You pretty much hit the nail on the head for my initial ideas about what I felt could be improved in the web interface. Authentication being a big one!

Good job and keep it up!


Programmer is $14 clone off E-Bay... Well worth the investment to do this upgrade.

South Africa

There is no ebay where I live, and international shipping to here is hit or miss unless you use DHL or similar.

(which is normally 3 times the price of the item) eyeroll


@PTP, Awesome work on this new firmware. I am working on indoor navigation project, is it possible you could add a way to view wifi access points and there signal strength? Also have this info available in ARC My hope is to use 3 APs signal strengths to triangulate my position.



Hello, when will this Firmware for Ezb-v4 be available?


This firmware is for the old discontinued EZ-B v4.x/1. The new EZ-B v4.x/2 has it's own firmware updater - which you most likely have the latest firmware if you've purchased it within the last few months.


Just stumbled across this...slowly getting used to the new forum!!:)

Great work @ptp