ISOBlue Near-term TODOs


#1

Hello guys!

This is Yang Wang and it was great to talk to some of you guys last Friday.

We went over ISOBlue 2.0’s hardware and software from a high level and some great questions were raised. It looks like for the short term, we will try to help you guys to get familiar with the parts and improve the SW and HW build process on our end.

We will try to shoot a series of videos that give detailed instructions on the making of ISOBlue 2.0 soon. Meanwhile, if you guys want to order some parts, please let me know and I will see if I could help.

If you guys could think about anything that could be useful for improving either the documentations or ISOBlue 2.0 in general. Please feel free to add more todos to this post.

Thanks in advance!


#2

Hey Yang, thanks for the great demo. We’re looking forward to the videos.

I know @Anne is planning to acquire parts; do you have preferred retailers/partners that she should check out?

I’m also curious to see your short-term dream TODO list: what would you implement/improve if you had all the time and resources in the world? :smiley: A more down-to-Earth list of things you’d like to have in order to streamline adoption by devs farmers is also fine (and maybe more useful :wink: ).


#3

Hello Simeon,

do you have preferred retailers/partners that she should check out?

Please checkout the BOM. It has the parts name as well as the vendor for each part. Some things to keep in mind:

  • The items in the BOM are not necessarily the cheapest out there. If you guys find cheaper ones, feel free to put a note or edit in the BOM spreadsheet.
  • The ISOBUS related ports and pins are often on back orders on Mouser although they are usually cheaper. Two alternative websites I found for ISOBUS related parts are Allied and Wirecare.
  • There are also some parts that will make you wonder “why do we use this here?” or “this looks extraneous”. These questions are probably more apparent when you are actually building one. I got these questions a lot when we had the build party. The reason is that due to time constraints, for the initial hardware design, I mostly picked parts that will make things work and connect with no problem so I didn’t research enough into what works the best. If you notice some awkwardness in hardware connections, feel free to let me know. If you have a better solution that you want to try, please go with it as well.

what would you implement/improve if you had all the time and resources in the world?

There are quite a bit and some of these are not short-term maybe. More of a dream list. :smile:

  • The top priority now is to make improvement to assembly instructions and make instruction videos on the making of ISOBlue 2.0s.
  • I really want to do a makeover on the where-is-my-isoblue site. This site is in really primitive function now. First off, it only shows visualizations when ISOBlue 2.0s are connected to the Internet. Then it displays where your tractors (ISOBlue 2.0s) are at and shows you the cell strengths in real time using the data pipeline we talked about last week. What we really want is a site that could give us visualizations on available machine status (fuel rate, speed, engine load, etc ) in real time. It would also be cool if we could display some historic data instead of only showing the visualizations when ISOBlue is connected as of now. The current site’s code can be found here.
  • The microservices in our Cloud also need some makeover. This relates to the where-is-my-isoblue site as well since they send the parsed data (GPS info, cell strength, etc) to the website using MQTT via websocket. They are functioning but they do not offer a infrastructure that is easily adaptable and expandable. What we want is building a real data ingesting and analytical pipeline using Apache Storm paired with the currently used Kafka or pretty much any other stream processing tools. If this were built properly, we could deploy all kinds of cool microservices onto the Cloud. Moreover, anybody who is interested in ag machine data could write their own microservice to get the pieces of data that they would like to get. You can find the current architecture diagram in slide 11 of this slideshow.
  • The next thing is to make ISOBlue 2.0 smarter and prettier: it can switch between the best available network (cell or Wifi). For instance, if the ISOBlue “knows” it has 10,000 messages left to push to the Cloud when the machine is off, it would notify the farmer or the manager that it is still catching up. The farmer could drive the machine to a place where Wifi is covered and ISOBlue would switch to it so that it could catch up faster. An additional feature that I always envision is using a smartphone to register and configure ISOBlue. Last but not least, we definitely want to have a prettier enclosure for ISOBlue 2.0!

#4

Hi Yang,

Thanks for your explanations above and pointing out some replacement suppliers.

We’re currently working on the BOM and looking for suppliers that deliver to NL etc.
Our current version can be found here: BOM
We’ve changed the LTE modem to support European carriers and we’re still looking for a suitable GPS module. The module you have used does not seem to be available anymore from the supplier.
Can you list the criteria you based your choice on, and check out our current choice?

Apart from the GPS module we’re basically complete. The ISOBus connector we’ll work out this weekend and hopefully order as well.

When you check out the BOM, you’ll see some items are highlighted red. We’ve changed these slightly to be able to aquire them cheaply. Blue items we’re still unsure on.

Thanks in advance!

Auke


#5

Hello Auke,

I had a quick look at the BOM. Most of the parts are fine. One thing I noted though: the GPS module Haicom Haicom HI-206III PS-II GPS muis has a RS232 interface with a PS/II connector and it is probably not gonna work with directly with the sealed USB connector we have.

The GR-801W module is the very few GPS modules that offer PPS over USB; the PPS signal synchronizes the time on ISOBlue and the current ISOBlue time synchronization software (chrony) is set up to watch the USB GPS device. I would highly recommend to use the GR-801W module if you do not want to reconfigure all the settings.


#6

Hi Yang,

I have contacted the people at navisys, and they mentioned that the GR801W module’s new internals (ublox8) do not seem to support 1 PPS signal, however, they mentioned an alternative: the GR701W module.
Can you confirm / deny that it is exactly “1 PPS” we’re looking for or is signal mentioned in the datasheet of the 701 ok as well?

We plan on ordering this module. Currently the only difference I found was that there is no support for NMEA version 4. Can you let us know if this is a problem or what version is currently being used?

Documentation of the GR701W can be found below.
GR 701 W

Thanks for your help.

Auke


#7

Hello Auke,

I looked at the GR701W module and I think this module should be fine. Some precautions though (I should’ve mentioned this in the last post but totally forgot about it):

ISOBlue uses gpsd to manage its interaction with the GPS module. On gpsd’s hardware web page, it has a list of the GPS modules that has been experimented or tested. We picked the GR801 module from this list. It says it doesn’t support PPS but Navisys implemented this feature when we ordered the module. I don’t see GR701 in this list but it doesn’t mean it will not work with gpsd. Therefore, if you want to be safe, you could inquire Navisys about GR601 and order those. But from specs in the GR701’s datasheet, I have confidence that it will work with gpsd.

I don’t see this as a huge problem.

Let me know if you have any other questions.

Regard,
Yang


#8

Hi Yang,

Thanks for your help so far!
I can happily anounce I have ordered all parts for the first Dutch Isoblue.
We’ll keep you updated on our progress!

Auke