Cobra II: few questions

Archive
1

I am playing with my Cobra II. I have few questions:

  1. When I change sound frequency for Tunes module, I can hear a click. How can I get rid of that? My code:
While True
    tunes.Play(CInt(analog.Read() * 6000))
    Thread.Sleep(25)
End While

  1. Is it possible to adjust responsiveness of Button module? Some of my quick clicks are not being registered.

  2. Is it possible to adjust update rate (StartContinuousMeasurements) of Temp&Humidity module? It too slow for me.

  3. Some of my set GPIOs turn on during boot-up, but I want them to be all the time low until I turn them high. How to achieve that?

2

  1. responsiveness of the button is a function of two things - the interrupt handling speed, and the actual contact responsiveness of the button itself. Try using your own interrupt handling code to see if that helps, but otherwise you’re likely to need to slow down your presses !

  2. Unlikely, unless you take the code and understand the driver yourself, and modify it appropriately. But why is it too slow, how frequent do you need ? How quickly do you think the temperature or the humidity changes, it’s actually a very slow process.

  3. If you need to be explicit about your state of your controlled pins on start up then you need to explicitly build in pull up or pull down resistors in your connected devices. You can’t guarantee that the initialisation of any pin at power-up will be in a particular state, and you can have something like a second delay before your code kicks in to set state.

3

What FW version are you using?
Do you have a RGB Display connected?
If you have no display connected and your FW is before 4.2.11.x then the RGB pins are configured as display by default and will change their state until you configure them.
With 4.2.11.0 and newer display is off (not configured) by default.
Also configuring display with FEZConfig when using a newer FW will result in changing RGB pins.

To get every button press you should use interrupt capable pins for them and use the interrupt events.
You can handle the event directly, or you might write them into a chain (or increase a press counter) and execute your actions in a different thread.

4

My FW is 4.2.11.1. I do not have any display connected. If there is enough current to light LEDs (all LEDs in my LED Strip module are on for a second while Cobra II boots), I believe pull-up or pull-down resistors won’t help here.

StartContinuousMeasurements updates every second or so. I would want to get update rates at least each 1/10 of the second. It will be used for data logging, so I need to capture changes more accurately (in terms of speed).

5

pull ups or downs explicitly hold a data signal to 3v3 or gnd, until driven by the IO. The problem you have at the moment is that they float and the LEDs light up; using pull-downs will certainly work, if you care enough to worry, but it DOES require you to do some work !

What rate of change do you expect to be able to handle? Are you talking about recording this in an oven? If you’re only talking about ambient air, I think you’ll find that the accuracy of these devices is not going to show you any meaningful data at .1 second interval, and even at 1 sec you won’t see change that dramatic. You really need to explain why you want to log that frequently; it’s unlikely to be necessary.

6

What pins are shwitching to high state on bootup. Make sure that no display is configured by connection with FEZConfig.

About Temp update rate.
If the ‘intelligent’ module is too slow, you might want to switch to analog sensors.
Then it’s only limited by the analogue input rate.
A rate of 100ms should be no problem there.
I should get my T&H modules soon (I hope so), then I can have a look into this too.

7

Display is not configured. All pins get high on my Led strip that is connected to (B, Y) port, led on Button module that is connected to (S, X) port also gets high.
I am not sure how Brett’s suggestion for pull-up/down resistors would work. During boot up, there is 66mA (!) going through GPIO pins, I would need 50R resistor to get rid of that, but in that case I would never be able to switch on those GPIOs.
You can see how it is originally wired and how I imagine I should wire with pull-down resistor. It does not make sense, but maybe I am missing something here?

I think ‘intelligent’ sensor can update much more faster than one update per second, but its update rate is set (without possibility to adjust) by the ‘driver’. Question is - would it be easy to modify it?

And what about Tunes module, do you have any thoughts how to get rid of that click sound?

8

I just went through the datashet of SHT1x chip.
http://robofun.ro/docs/sht1.pdf
According to that it does not have a function for continuous measuring.
So I assume it’s implemented in the driver.
The time to measure a single value depends on the adjustable accuracy and ranges from 20 to 320ms.
So if it’s set to 14 bits, and you want to read temp and humidity, measuring alone takes 640ms. Plus communication / NETMF overhead you might get not more than 1 measurement per sec.
Going back to 12 bits would reduce sampling time to 80ms
To do so you need to modify the status register of the chip.

9

SHT10 chip is used. Yes, you are right about resolution & speed, and you are right that continuous measurements are implemented in driver.

Driver with comments takes 308 lines and seems to be easy to understand and modify. There is one thing I don’t like here:

    private void TakeMeasurements()
    {
      Thread.Sleep(11);
      while (true)
      {
        if (this._measurementRequested || this._continuousMeasurement)
        {
          //...
          Thread.Sleep(3600);
        }
        Thread.Sleep(100);
      }
    }

Driver does not allow to reduce resolution (and hence increase reading speed) and it also deliberately delays those readings.

10

You could modify the driver to your needs, that’s why it’s open source :slight_smile:

Edit: btw. Why do you need to read that fast? Temperature and humidity usually does not change that fast.

11

So it seems driver is already reading at 12bit accuracy, and 3.6s delays is added to prevent sensor from warming up. So I will have to use another sensor.

What about those pull-ups? Can anyone help me with that?

P.S. In my controlled environment temperature will change fast. And no, I won’t measure room temperature :wink:

12

Hi,
if you only want to control a LED, I think it should be possible to do it like this:

13

Yes, that will work for LEDs. And if I want to control transistors & mosfets, how should circuit look then?

I would be surprised there is no possibility to turn this ‘feature’ off. I have worked a bit with PICs and MSP430, and there was no such problem. Btw, during boot up I get momentary 1V7, not 3V3.

14

@ iamin - I had an similar voltage on an GPIO output (1V7) once.
My problem there was that two outputs have been connected (short circuit). If one was high and one low, then I got more or less half of 3V3.
Just wanted to mention that.

15

Thanks for your information.
Let’s hope any of GHI staff members will comment on this ‘feature’ (issue).

16

So lets be explicit here. If you read 1v7, then there’s a good chance what you’re actually seeing here is a signal being sent to the pin, but you only detect an “average”… unless you’re using an oscilloscope?

You said you were using the socket marked B, Y, so I assume that you mean SOCKET 1 on a Cobra2. That socket is meant to be used by the LCD, so there’s a good chance that what you’re actually seeing is the LCD being initialised, even though you said a display was not configured.

Lets turn the question around. How do we verify that the LCD initialisation is not occurring, or force it to not occur? (out of interest, I connected a Led7R up to Socket 1 on my Cobra2 that has never had an LCD on it either, and some of the LEDs light up on it)

But lets also not forget, the rule with circuits on microcontrollers is that someone else decides what the initial pin state is, and that can and does change between even “drop in” replacement parts - and so for you, if you explicitly need the state to be a certain way, then you have to design a circuit to explicitly start that way. For example, to properly control a relay’s state through a transistor or a FET, you want to make sure you don’t let the pin float or go into Hi-Z state and you’d tie it to ground to not enable the relay and switch on your load.

17

May be that there is not one solution for all possible conditions.
I think to find a solution one should know which kind of electronic component is to be controlled, what will happen if there is not the desired logical state at a specific time, whether it’s time-critical or not. In some cases perhaps an inverter will be ok, in other cases perhaps a logic AND-circuit with Schmitt-Trigger and one input held low by an RC-element will do the job.
Anyway it would be fine if the mcu could be programmed how to behave on the next powering up or reset. People of GHI should know if such features are provided.

18

I use good DMM, as LEDs are on for at least .5s, I can tell it is not an average but true 1V7.

Yes, it is socket 1. Maybe LCD is being initialized (even though it should not be), that does not explain why LED on Button module (that is connected to socket 6) does also light up (also 1V7).

All 7 LEDs light up on my LED Strip module. You can try another test: connect LED to any pin, any socket and it will light up at half brightness during power up.

For example with MSP430, I can set up pull-up, pull-down or no resistor within software. If it is not possible with ARM Cortex-M3, I can add up my own resistors, but I would not be happy if I would need to use “logic AND-circuit with Schmitt-Trigger” as it would be too complicated, I believe.

19

So let me reiterate a point here - you don’t get to decide what state a pin is in on startup. The chip manufacturer does. They may choose to set Hi-Z on all pins, or they may choose to set to high, or low, or they may choose to set a mix depending on what peripheral is tied to it (for example, a UART may need to leave TX and RX in a certain state, not Hi-Z).

The best you can do is to immediately configure them when you get control of the chip. Your MSP430 example just supports this - you’re only setting that in your code.

In the case of a netmf device, your app loads well after the netmf and the setup of the peripherals based on the firmware from the hardware vendor. So even if the first thing you do in your app is set your state, that’s well past the hardware initialisation that the chip itself has done, and that the firmware has done. Your point about a Cortex M3 chip is irrelevant - you’re not programming one of those, you’re programming a Cobra 2 from GHI - even if GHI use a Cortex M3 on the Cobra2. (again, this just reiterates, the decision is not yours)

If you are reading 1v7 with a DMM, then you are possibly reading Hi-Z or you’re possibly reading a fast digital signal. I can’t tell you which though - and I don’t have a O’scope to be more helpful.

Why does Socket 6 behave similarly? Well, again, there are specific hardware peripherals associated with those pins (SPI for example) that the firmware may configure or set, or there’s a device on that bus that shares those signal pins.

“You can try another test: connect LED to any pin, any socket and it will light up at half brightness during power up.”

I have connected my LED7R across many sockets (not all), and some of them show Hi-Z (dim) and some show off, depending on the socket. So if you see all LEDs dimly lit on any socket, then we are not seeing the same thing.

But again, if you are expecting to have a specific state at startup you need to take specific electrical actions to achieve that. What we need to work through here is what pins should and should not change state when the LCD is not enabled, to minimise the number of pins where that may be necessary.

20

@ iamin -

[quote]
For example with MSP430, I can set up pull-up, pull-down or no resistor within software. If it is not possible with ARM Cortex-M3, I can add up my own resistors, but I would not be happy if I would need to use “logic AND-circuit with Schmitt-Trigger” as it would be too complicated, I believe.[/quote]

It should not be to complicated. You could use two Breakout Modules and put one 74LS241 between them and hold the Gate-Inputs low for some time with an RC-element.