Thanks, nice and cheap board there.

 

I know pretty much which ICs are out there, I was thinking more of the backup method itself when creating ones own circuit.

 

Sorry for being unclear about that.

Yes, just like those found on computer main boards (which use the same kind of IC) I was just a little surprised that a super capacitor can maintain its charge for such a relatively long time (depending on the load of course).

Hi all! I'm just wondering what you guys use to backup your RTCs, are you using coin cells, super capacitors or what? Also, does anyone know of an RTC chip with an integrated backup and clock? Thanks.

Two weeks is pretty good, especially if the intention (like mine) is merely being able to survive a reboot due to watchdog timeout or a temporary power shortage.

Ok, so basically you are using another uC (picaxe) to do the 1-wire talking and have your Netduino talk to that over serial, correct? Regarding the RTC itself, I'll probably do like emg, buy a ready made board from eBay.

Hmm...those small re-charging cells seem nice and 15 pieces for less than 1 USD is within my budget too!

 

Seems to be like a combination of battery and super capacitor?

Note the "these batteries will discharge over a period of time (even if not connected to a circuit)" remark. I'd try to avoid that. I wonder how long this would work in practice with an STM32?

As I understand, it is being charged when your board is powered the normal way but if power is lost, the cell will power the RTC chip for a certain amount of time depending on its current draw and the minimum voltage it requires to maintain time keeping (usually ~1.8V). The cell is not supposed to power the whole board, just the RTC chip.

...P.S. The DS1904 iButton has a built-in battery. Also, the Thermochron DS1921G.

 

Thanks, I really would prefer something with both crystal and battery inside the chip but it never occurred to me that some "Dallas keys" have that.

 

Those coins are really great but what about one wire support - is that doable on Netduino with latest firmware?

 

I recall seeing other devices with integrated battery but I can't seem to find any know. Do you know of any besides the Dallas keys?

Found this "CAPHAT" device from ST in a DIP24 package and I2C interface:

 

http://www.st.com/we...ferrer=70071840

 

It has an integrated crystal and battery with automatic switch-over circuitry. It seems rather old and its very big due to the integrated battery (only 5 of 24 pins are used) and draws some 300uA which is quite a lot these days. On the other hand, it's a single chip breadboard friendly solution and it is in fact still active.

 

What you guys think about that one?

 

EDIT: ST also has these more advanced RTC chips with an optional SNAPHAT containing a battery (replaceable) and crystal that you snap on as a cover on top of the chip. A special version of the chip is then required that has SNAPHAT mounting pads on its top.

http://www.st.com/st.../CD00002304.pdf

Kickstarter has a very low tolerance for antagonists. Having an account on kickstarter is a privilege.

That sentence pretty much summarizes what I disapprove of - the lack of balance. A crowd of yey-sayers can easily contribute in creating an unjustified hype over something that you are not allowed to be critical of. That's just does not seem right to me. How could it be a privildge to have an account, the account holders usually pay money, don't they? The priviledged ones ought to be the project owners. I can only imagine how much hard work it takes to get a project up there and reaching the monetary goals, but then again, it's not supposed to be easy either. Don't get me wrong now, I'm not against the Kickstarter concept in essence and also have nothing against the Agent smartwatch or any other Kickstarter project for that matter. It's the lack of balance I'm against. In fact, I really love the Kickstarter idea - it's a great way for people to get great products on the market using the common approval rather than that of a few capitalists and the kind of control they usually imply. There's so much great talent and potential out there and I think Kickstarter presents a fantastic opportunity for those to come into the open.

...Is it really the first one?

As a web server I think not but as Networked Attached Storage, I suppose it is. In a data acquisition application you don't have to take the card out to examine the log which ought to be an appreciated feature.

 

It is fully self made (the C# standard libs, like Windows.Forms and System.Net.WebClient are used, but I think it's not what you meaned?

in DuinoFinder I used the same code, but the GUI (there I took Gtk instead of Windows.Forms, what is also for Unix available))

I was thinking more in terms of whether you can access the files as kind of a network share like SAMBA (or something like that) using the standard Windows Explorer. I get that impression from looking at your pictures.

 

Sorry, I don't know, I haven't made any investigations in that direction yet. My devices have only a single slot for SD card. Is there an extra hardware necessary?

I didn't mean that seriously but yes, you would need an external SD card slot and drive that over SPI.

Ah, the world's first Netduino NAS - very nice work!

 

About the Duinoexplorer - is that a fully custom made application or does it somehow integrate with windows?

 

What transfer speed can you reach when downloading a reasonably large file?

 

Does it support uploads too?

 

If you put a second SD card in there, you could have software RAID too 

I see. What are you using this for yourself?

You should use an interlocked exchange to change the value of the _serverReady varible. The Interlocked.Exchange method will replace the value and return the previous value in a single atomic (unbreakable) operation.

int _serverReady = 1;if(Interlocked.Exchange(ref _serverReady, 0) == 1){            // process request       .      .      .      // done, open unlock the door      _serverReady = 1;}else{      // server busy}

As indicated above, I think you have to declare _serverReady as an integer for this work. You might want to use the volatile modifier on your variable declaration but I don't know if that feally matters in .NETMF. There might also be a way to configure the listener as synchronous so that the server will never attempt to process requests in parallel. Could be this feature is not available in .NETMF, I'm not sure.

That is a great example of a very useful Netduino application and nice to see you've finished the project. The optical feedback system was really clever, it's always good when you can keep it non-intrusive.

Sample rate and stereo/mono mode are properties of the song you are playing and so they depend on how each song was recorded. I added this info just for fun and it should not effect how well or poor a song is played. By the sound of it, you are suffering from poor transfer rate between the SD card (songs are on an SD card right?) and the vs1053b. If you look into my code, you can see that I crank up SPI speed as part of initialization. Have you incorporated that part into your code? Also I remember someone else had similar problems not all that long ago where I tried to help. Use google to search the forum for "vs1053b", the forum search does not work very well (or maybe it does now). Also, you cannot have Debug.Print in performance critical parts of your code, it will slow you down a great deal. I assume you don't use interrupts for DREQ since it too will add significant overhead. You must poll DREQ in a tight loop and then feed the chip fresh chunks of 32 bytes each as quickly as you can until DREQ changes again to indicate the buffer is now full and cannot accept any more data until the chip has consumed what you just fed it. Now, I did this with a mini which is considerably slower that an NP2 but I recall there were some problems mentioned in the thread I mentioned above.

I remember  initially having quite some trouble with getting the chip to play. My problems turned out to be SPI related and at some point, I got a faulty GPIO pin connected to DREQ which was really hard to track down.

 

If you haven't already, take a look at this post:

http://forums.netdui...decoder-solved/

 

I posted on the VLSI support forums and among others, there's this one:

http://www.vsdsp-for....php?f=11&t=277

 

I've made many more posts on the vs1053b department of the VLSI forum. Please do search for my posts over there and I'm pretty sure you will find something useful:

http://www.vsdsp-for...id=298&sr=posts

 

Hope this helps!

So, basically you're running the same s/w as me, then it ought to work especially on a faster uC. Well, at least one would think so but... Here's the thread I was thinking about in my last post: http://forums.netdui...ge-3#entry44437 It took me a while before I realized it's my own old thread but I believe it might be very relevant indeed from the post referred to and onwards, so read it carefully.

Hi tuff!  

I haven't taken the time to look through your code but in the post below, you'll find code that is known to work perfectly well with Netduino mini and should work equally well with a NP2 after a few modifications.

 

http://forums.netdui...ge-2#entry35811

 

The code is stripped from stuff that are specific to my application and the remaining code is very simplistic which makes it fairly easy to follow and use as kind of a  ground to work from. For example, you'd have to add your existing code for fancy things like changing volume, etc. The code simply plays all songs from and SD card, one song after the other.

 

Also, there might be some reading of interest from that post on-wards.

 

Hope this helps!

If you mean what the pin is used for, I believe it is for supply voltage 7.5 - 9V.

Are you sure the name even sticks to the board?

I have been able to display 2 different characters on the display now however I am still unsure on how to "push" new characters to the screen.  In my code it is just a while loop switching between displaying the first digit and the second digit, preventing me from sending it a new character.  I would like to be able to write a function that writes to the display and keeps it there until another command is set.  I believe this is accomplished by threading a method to keep the screen 'alive' and send it an event(?) to update it.  I haven't used events or threading before however so I'm not sure how to implement it yet so any help is appreciated. 

 

 

Since characters currently don't "stick" you are doing multiplexing by looping while toggling between the two digits. Sure, you could do the multiplex loop in a thread but there's a good chance it will flicker depending on how much and what you do in your main thread. To get "sticky" characters, you'd have to use some kind of slave chip like the ones suggested some of the other guys earlier in this thread.

 

As for "pushing in" arbitrary characters, you could display other letters quite easily by simply reading them from an array of digits or something like that.

 

Consider creating a base class "Digit" for setting the GPIOs for any given character you wan't to display in either of the two 7-segment digits. The class could have a method called "Render()" that would set the GPIOs as necessary depending on which character the class instance represents.

 

You could then derive one sub class from "Digit" for each character that you need, i.e. among others, you would have sub classes DigitH, DigitI and Digit0...Digit9 and so forth overriding the Render method. You could then create and dictionary of Digit objects and simply index the array using the corresponding ASCII character taken from the string(s) that you want to display, i.e. "HI", "40" etc.

 

This software approach can be used regardless of whether or not you choose to use a slave chip.

Using SPI to control a single shiftreg, wouldn't that require a pretty tight loop for multiplexing a 2-digit 7-segment display?

Yes, most of what has already been done is HID since that is one of the simplest device classes to implement and won't require a dedicated driver on the host PC. If I recall correctly, a CDC device will require a driver. All in all it's a big thing to take on.

Hi!

I think some work has been done in this direction, google returns some hits when searching for usb + cdc:

http://lmgtfy.com/?q...o.com usb + cdc

Also forum member Oz made a HID keyboard a while back:

http://forums.netdui...d-updated-code/

In either case, I think the normal programming/debugging device will no longer be available so you have to switch to serial deployment.

Hopefully, the above will get you started. Good luck!