# emonSD next steps **URL:** \ **Category:** emonSD\ **Created:** [18 March 2019 15:12 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426 "2019-03-18T15:12:03Z")\ **Posts on this page:** 1\ **Showing post:** 42
**Author:** ![Greebo](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/greebo/32/4556_2.png) [@Greebo](https://community.openenergymonitor.org/u/Greebo)\ **Post date:** [25 March 2019 11:56 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/42 "2019-03-25T11:56:45Z")
> [@pb66](#): > > ![](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/greebo/40/4556_2.png) Greebo: > > > I think there was already general consensus that the firmware and software stacks would be separated, so there’s no minority here (unless its silent on the matter!)… > > Exactly, however, whatever your views the decision is in the hands of G&T and they want it the way it is, hence my suggestion to keep it close to the way it is by default. It is IMO the best we will achieve. I’m pretty sure they were on board - especially since the firmware has been static for so long. I’ll try and find the post… [EDIT] Found it… > [@emonSD first boot](https://community.openenergymonitor.org/t/emonsd-first-boot/10419/11): > > The only way to detect would be to test the different baud rates. However, updating the RFM69Pi firmware is unlikely to be needed, there has been any changes to the RFM60Pi firmware since 2016: [Release V1.3.0 · openenergymonitor/RFM2Pi · GitHub](https://github.com/openenergymonitor/RFM2Pi/releases/tag/1.3.0). Therefore, as an emonBase user is doesn’t really matter if you run emonPi update instead of emonBase update since there is no new FW updates. I agree, it would be good to make the microcontroller FW update a separate process from the emoncms update --- _[View the full topic](https://community.openenergymonitor.org/t/emonsd-next-steps/10426)._