DFRobot Modules I ordered arrived

Archive
1

First, score for DHL as I ordered these late Tuesday night and today (Friday afternoon) they arrived from China (SHANGHAI -> CINCINNATI -> SEATTLE -> CALGARY), so between DFRobot and DHL their shipping rocks.

I ordered two UV Sensors and one SD2403 Real -Time clock Module. The UV Sensors came with header pins which could be attached whereas the Real-Time Clock module has the header pins already attached. Now I don’t care about those pins at the moment as I’m planning on using these modules with Gadgeteer. One very interesting thing is however the modules have dates on them:

SD2403 Real -Time clock Module 30/05/2012
UV Sensor - 5/31/2012

which makes me think DFRobot has had the idea of building Gadgeteer modules on the fire for awhile.

The kicker is there was no disk or anything with drivers in the box, nor any URL from which to download them. I just sent their support group an email, but I have this feeling that they don’t do Gadgeteer drivers, which is no doubt a bit of a speed bump. There are wiki’s on DFRobot which have Ardunio type source code examples for these modules, so looks like I’ll be using those to come up with some drivers at some point which kind of sucks as I have a project I could use the UV sensor on right now, but given I was thinking of posting this project this weekend, the UV Sensor likely won’t be ready.

2

Like I said before… I suspect this is another Seeeduation :wink:

3

Another Seeedulation, well I’m not so sure that Seeedulation turned out really that bad. Granted GHI Electronics picked up the slack, but GHI Electronics is always my first source for modules because they are pretty much a turn key solution (I’m still waiting to see what those next 10 modules are Gus), but having purchased modules from pretty much every module vendor I can find has it made it pretty apparent to me that turn key solutions across the board might not be feasible (but they will always be my first choice where possible). I often find that small third party guys are really hardware gurus and their mind candy comes from designing the hardware etc and either they aren’t as interested in the software side or frankly just don’t have time for the software side of their product (you know who you guys are), so what to do? Certainly as a maker of devices, I want those hardware guys to be building hardware and perhaps the software side of the community might have jump in and help build some public source drivers. There are some upsides to this as well, for example I feel fairly confident that GHI isn’t going to disappear overnight so I don’t worry about their drivers going bye-bye either (and most of the code is in the Gadgeteer project on CodePlex anyways), but some of the one man module shop dudes, well they could vanish overnight (ie their real job eats all their time/resources/etc) and having their driver modules on CodePlex might be a really good idea both both the maker of modules and their buyers.

So what to do now. I have a project that I was hoping to release to CodeShare, YouTube etc tomorrow and the UV Sensor might have been a very cool addition, but I’m going ahead with the release and the DFRobot modules will have to wait for another day when I have some time to learn more about Gadgeteer drivers and write them (I’ve been modifying existing drivers where needed, but this would be my first ground up driver). Certainly I’ll put my efforts up on CodePlex for others to have or improve upon as well.

NOTE I don’t buy modules from Seeed anymore, as I get my ‘Seeed’ modules from GHI Electronics as I figure they are supporting them, they should get a healthy cut of sales to help make up for that.

4

I think the challenge to Chinese companies is in learning netmf and gadgeteer. This has got to happen sooner or later. So we as a community should help them till then. How awesome would it be it we see hundreds of Chinese companies making all kind of cheap modules :slight_smile:

GHI will have tough competition but we like to be challenged :slight_smile:

5

Personally, I think if you’re not going to produce a good driver to go with your module then you shouldn’t bother. What makes Gadgeteer awesome is its plug & play nature and you can’t do that without having both parts. Seeed thought they could quickly throw out a handful of modules and one-time write drivers for them and be done. Frankly, if it weren’t for GHI upgrading their driver for them then they probably would be completely done by now. I don’t speak for GHI, but I suspect that’s not something they want to continue doing.

Aside from the driver issues, there have also been hardware quality issues that they would not even respond to GHI about in a timely manner. I won’t buy any more modules made by Seeed or any one else that doesn’t directly provide and support said module. The simple truth is that the hardware side of 90% of the modules out there could easily be designed & produced by most people on this forum willing to take the time to do it. What makes a module great is the software that makes it useful.

I could support a community driven driver community IF the hardware support was excellent and the vendor at least produces the first version of the driver and makes it fully open via a GitHub or CodePlex project (not part of the main Gadgeteer project)

6

My view is perhaps not as clear.

The people who are good at modules are not always good at software.

For the best experience, a Gadgeteer module requires both rock solid hardware and great software.

A small organisation or an individual who is great at doing hardware and who makes a module and opts to put a .05" Gadgeteer header on it - whether as the only connector or as an optional connection to open the module to a wider audience - may not do a good job at a driver, or may not have the experience in the driver development for .netmf. (there are always exceptions*)

So is there a middle ground, where someone says I want to integrate a particular chip/hardware solution and offer it to the Gadgeteer community, but I don’t want to be the first one to develop a driver or to provide a comprehensive driver? I think there is. It’s no real difference to someone offering a shield for an arduino but leaving the coding to others; and over time that might become a defacto driver, and it gives us access to potentially a wider range of devices than we would have before.

Is there a reason why a commercial organisation can’t deliver a module without a driver? Not really, although I would argue that at some point there’s a responsibility that says they should be clear that they don’t provide a driver, and be clear what support they will offer. Perhaps that’s as simple as saying that the module offers a “Gadgeteer compatible connector” rather than it being a Gadgeteer module? I would agree with Ian though in that the ideal experience with Gadgeteer for someone who is not experienced in chip-level comms etc is in the connect-and-forget nature, so devaluing that is something we as a community should be aware of and helping point this out to vendors and newbies alike.

Exception* — We have some great exceptions for “real software” guys who have put together great drivers for modules so my expectation is that largely people who are active in this community are more likely to do a good job on the driver.

7

I was really happy to see their OLEDs with Gadgeteer AND PTH. Now I can use OLED on Cerb40 without needing an extender module. :slight_smile:

8

I think Brett has it right. I’ve just built my first module tonight. I will be posting about it tomorrow. I’m not a software or a hardware guy and I’m learning about both through gadgeteer. I have created a driver for my module and will be posting the vs project to codeshare as I am pretty certain someone else will be able to make a much better job of it. Indeed I expect it. I see no reason why if a hardware guy builds a module that the rest of the community can chip in and help create the software. It benefits everyone in the end.

9

I agree totally that it should be done as you have done it. Like I said, the creator of the module should at least create the first version of the driver so that people not willing to create their own driver are not left with a useless module if they buy it before the community steps in.

Can’t wait to see your module. Your first? Didn’t you post some pics of another module a few weeks back?

10

I should mention that DFRobot released a new Gadgeteer module, DFRduino Player module

So it appears they are getting further into the game. Hopefully I can find some time this weekend to post a driver for one of the modules I bought.

1 Like
11

I posteda pic of rev 1 DSLR which was incorrectly wired (read backwards) the other one is the one in the post was the gadgeteer -electric imp module which is in process.
The DSLR module is the first real released board :slight_smile:

12

Dear Duke: I got my UV module and testing it.
How do you decide the UVI in your driver?

double UVI = (((volts * 3300) / 4.3) - 45) / 27.0;

Thanks

13

Duke, did you ever create a driver for the Player module?

14 


        /// <summary>
        /// Returns the current UV Level reading of the UV sensor
        /// </summary>
        public double GetUVI()
        {
            double volts = ReadUVSensorVoltage();

            double UVI = (((volts * 3300) / 4.3) - 45) / 27.0;

            if (UVI < 0)
                return 0.0;
            else
                return UVI;
        }
15

Nope but I think there might be some help coming :slight_smile:

16

Dear Duke .

I know where the calculation you give.
I mean how do you decide the formula.

The wiki give a relation between mV and UVI.
UV_Sensor__SKU_TOY0044_-DFRobot

Thanks

17

http://www.dfrobot.com/image/data/TOY0044/UVS10.pdf would be the link.