The Logic Level Converters are these https://www.sparkfun.com/products/8745

I had buzzed out the connections high and low side, so I am pretty confident they are behaving normally.

The module is powered from the 5v bus on the arduino, however I have just checked the 3v3 max current draw an its 50mA max from the Arduino, however the specs show it can draw up to 69mA in active sensor mode. That also doesn't take into account the current drawn by the Level Converters either.

Looks like I will have to sort out a breadboard psu and a 3v3 arduino so I can stop using those level converters and clean up the wiring.

I suspect this project needs to be paused until the above are sourced. Thanks for all your help so far, I will keep everyone updated.

Sadly yes, still the annoying FF SurferTim.

As requested here is a schematic.


Larger - http://i.imgur.com/xz7fIjM.png

And the rats nest.....


Larger - http://i.imgur.com/SUKWy9v.jpg

I beleive I have integrated your suggestions into the latest revision of the code SurferTim (sorry I hadnt spotted the Microsecond delays in the first readthrough)

Code:

/*
 Example 34.1 - SPI bus demo using a Microchip MCP4162 digital potentiometer [http://bit.ly/iwDmnd]
 http://tronixstuff.com/tutorials > chapter 34 | CC by-sa-nc | John Boxall
*/

#include "SPI.h" // necessary library

byte values[3];
int CS=10;

void setup()
{
  pinMode(CS, OUTPUT); // we use this for SS pin
  digitalWrite(CS, HIGH);

  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE1);
  SPI.setClockDivider(SPI_CLOCK_DIV8);
  
  digitalWrite(CS, LOW);
  delayMicroseconds(1);
  
  //device intitialise
  SPI.transfer(0x30); //address byte
  SPI.transfer(0x43); //Status Register byte
  SPI.transfer(0x03); //New Status Byte - 0x00 – SLEEP, 0x01 – IDLE, 0x02 – SENSOR, 0x03 – ACTIVE The device is fully powered on. GPS is enabled. All the commands on mSPI are serviced.
  
  //GPS Initialise
  byte data1 = SPI.transfer(0x73); //GPS Mode Register
  byte data2 = SPI.transfer(0x02); //Set 10Hz update mode
  
  //Module Config Readback
  byte data3 = SPI.transfer(0x40); //Read Device Config
  byte data4 = SPI.transfer(0x70); //Read GPS Config
  
  digitalWrite(CS, HIGH);
  
  delay(1000);
  
  // Device Config Response
  Serial.begin(9600);
  Serial.print("Data1 = ");
  Serial.println(data1, HEX);
  Serial.print("Data2 = ");
  Serial.println(data2, HEX);
  Serial.print("Data3 = ");
  Serial.println(data3, HEX);
  Serial.print("Data4 = ");
  Serial.println(data4, HEX);
}

void loop()
{
  digitalWrite(CS, LOW);
  delayMicroseconds(1);
    
  SPI.transfer(0x30);
 
  //Continue to read registers until we've read the number specified, storing the results to the input buffer.

  for(int i=0; i<3; i++){
    values[i] = SPI.transfer(0x70);
  }
 
  digitalWrite(CS, HIGH);

  for(int i=0; i<3; i++){
     Serial.println(values[i]);
  }

  Serial.println("Hello?");
  delay(1000);
  
}

This still gave me the dreaded FF's

So in an effort to see if it was an issue with my wiring (I am using a pair of Sparkfun Logic Level converters, so there are quite a few hookups) I tried a simple SPI loopback program. I had to change the SPI_CLOCK_DIV to 64 before I saw the same values that went out, come back. The same couldn't be said for the GOM :/

Code:

/*
 Example 34.1 - SPI bus demo using a Microchip MCP4162 digital potentiometer [http://bit.ly/iwDmnd]
 http://tronixstuff.com/tutorials > chapter 34 | CC by-sa-nc | John Boxall
*/

#include "SPI.h" // necessary library

byte values[3];
int CS=10;

void setup()
{
  pinMode(CS, OUTPUT); // we use this for SS pin
  digitalWrite(CS, HIGH);

  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE1);
  SPI.setClockDivider(SPI_CLOCK_DIV64);

  Serial.begin(9600);
}

void loop()
{
  digitalWrite(CS, LOW);
  delayMicroseconds(1);
    
  byte data1 = SPI.transfer(0x00);
  byte data2 = SPI.transfer(0x22);
  byte data3 = SPI.transfer(0x33);
  byte data4 = SPI.transfer(0xFF);

  digitalWrite(CS, HIGH);
  
  Serial.println(data1, HEX);
  Serial.println(data2, HEX);
  Serial.println(data3, HEX);
  Serial.println(data4, HEX);

  delay(1000);
  
}

Further tests with the echo test indicate that 'FF' is the default response to "not connected".

I clearly need a Logic Analyser to see if any packets are even coming back from the module.

I rewired everything and now my code now looks like the following, sadly still no major improvements.

Code:

/*
 Example 34.1 - SPI bus demo using a Microchip MCP4162 digital potentiometer [http://bit.ly/iwDmnd]
 http://tronixstuff.com/tutorials > chapter 34 | CC by-sa-nc | John Boxall
*/

#include "SPI.h" // necessary library

byte values[3];
int CS=10;

void setup()
{
  pinMode(CS, OUTPUT); // we use this for SS pin
  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE1);
  SPI.setClockDivider(SPI_CLOCK_DIV8);
 
  digitalWrite(CS, LOW);
  delay(1);
    SPI.transfer(0x30); //address byte
    SPI.transfer(0x73); //GPS Mode Register
    SPI.transfer(0x02); //Set 10Hz update mode
  digitalWrite(CS, HIGH);
 
  Serial.begin(9600);
}

void loop()
{
  digitalWrite(CS, LOW);
    delay(1);
   
  SPI.transfer(0x30);
 
  //Continue to read registers until we've read the number specified, storing the results to the input buffer.

  for(int i=0; i<3; i++){
    values[i] = SPI.transfer(0x70);
  }
 
  digitalWrite(CS, HIGH);

  for(int i=0; i<3; i++){
     Serial.println(values[i]);
  }

  Serial.println("Hello?");
  delay(1000);
}

My output looks like this.

Code:

255
255
255
Hello?
255
255
255
Hello?
255
255
255
Hello?

Which is at least as expected moving from char to byte, however still represents the same 0xFF.

Going to see if I cant find someone with an Analyser to plug it into, if not I suppose its a chance to buy a new toy tool.

Tim and Nick, many thanks for your help. If anyone spots anything else, I am gratefully receiving suggestions, they don't even need to be on a postcard!

Cheers for the heads up, I had taken my LSB requirement from "Section 4.3 Available Commands" where everything lists as LSB. I foolishly made the assumption it was all like that.

However this simple change has had no effect on the output, so I suspect I have something else wrong

Hi all, I wonder is people could point me in the right direction.

I am attempting to read multiple bytes of data coming back on a modified SPI interface from a combined GPS, Acellerometer, Compass, Thermometer sensor module from Dimitech.

http://www.dimitech.com/downloads/dtx1-2820l.pdf

I'm having a hell of a time with it. 

I thought I would start small and just read back the configuration of the GPS module on the board, using the Address/Command structure from the data sheet.



Which I take to mean, pull the CS low, send the Address (0x30), send the register to read (0x40, GPS mode register). It will then send the "dummy" packing byte of 0xFF, the data "payload" and then its own address (0x30 again) to signal the final packet.

Below is my code which is a mashup of a tronixstuff tutorial and the SparkFun ADXL345_Basic.pde

Code:

/*
 Example 34.1 - SPI bus demo using a Microchip MCP4162 digital potentiometer [http://bit.ly/iwDmnd]
 http://tronixstuff.com/tutorials > chapter 34 | CC by-sa-nc | John Boxall
*/

#include "SPI.h" // necessary library

char values[3];

void setup()
{
  pinMode(10, OUTPUT); // we use this for SS pin
  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(LSBFIRST);
  SPI.setDataMode(SPI_MODE1);
  SPI.setClockDivider(8);
 
  digitalWrite(10, LOW);
    SPI.transfer(0x30); //address byte
    SPI.transfer(0x73); //GPS Mode Register
    SPI.transfer(0x02); //Set 10Hz update mode
  digitalWrite(10, HIGH);
 
  Serial.begin(9600);
}

void loop()
{
  digitalWrite(10, LOW);
 
  SPI.transfer(0x30);
 
  //Continue to read registers until we've read the number specified, storing the results to the input buffer.

  for(int i=0; i<3; i++){
    values[i] = SPI.transfer(0x70); //GPS Status Read byte
  }
 
  digitalWrite(10, HIGH);

  for(int i=0; i<3; i++){
     Serial.println(values[i], HEX);
  }

  Serial.println("Hello?");
  delay(1000);
}

And a sample of what I see in the serial monitor window.

Code:

FFFFFFFF
FFFFFFFF
FFFFFFFF
Hello?
FFFFFFFF
FFFFFFFF
FFFFFFFF
Hello?
FFFFFFFF
FFFFFFFF
FFFFFFFF
Hello?

I believe I am supposed to receive back an 0xFF (dummy byte), 0x02 (10Hz mode) and finally 0x30, its address signalling the end of the transfer.



Any suggestions?

Cheers
   Gregg.

Musical christmas light and DIY DJ's across the globe now have a new friend.

Also featured on Make - http://blog.makezine.com/archive/2010/11/real-time_spectrum_analyzer_powered.html

I really wish x10 had taken off in the UK, the modules are so expensive.

Ebay is an invaluable resource so I may just get the 110v units and get cracking modifying them. The SocketRocket Lamp modules would be perfect for controlling building lights if you just need on/off control and can be had for as little as $5 each on ebay vs. the $24 they want for UK spec at retail.

The dimmable lamp modules are available for $18.99 which is about the same as we pay per module!

Quick braindump for a VU meter that I have whizzed up this afternoon since I received my hardware.

It's quick and its dirty because I haven't received the components to build my rectifier circuits yet.

It makes use of desinger2k2's work on speeding up the LCD display - http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1240088162/0 (although I had to do additional work to make my screen+buttons shield to work)

Code:

#include <LCD4Bit_fast.h>

LCD4Bit_fast lcd = LCD4Bit_fast(2);

void setup() {
  
  
  lcd.init();                             //Inits the LCD

}

void loop() {  

  //int i=(analogRead(1)/64); //readin Analog 1 (Left) calibrate for screen
  //int j=(analogRead(2)/64); //readin Analog 2 (Right) calibrate for screen
  
  int i=random(2,14);       //simulated input
  int j=i+(random(-2,2));   //simulated input
  int x=0;
  int y=0;
 
  lcd.clear();

 lcd.commandWrite(0x80+11); //Place cursor at row 1 col 0 and add i to the col
 lcd.printIn("|"); //fill character with ]
  lcd.commandWrite(0xC0+11); //Place cursor at row 1 col 0 and add i to the col
 lcd.printIn("|"); //fill character with ]
  
 while (x <= i)
  {
    lcd.commandWrite(0x80+x); //Place cursor at row 1 col 0 and add x to the col
    if (x > 11)
    {
      lcd.print(255);
    }
    else
    {
    lcd.printIn("="); //fill character with white
    }
    x++;
  }
 
  while (y <= j)
  {
    lcd.commandWrite(0xC0+y); //Place cursor at row 2 col 0 and add y to the col
    if (y > 11)
    {
      lcd.print(255);
    }
    else
    {
    lcd.printIn("="); //fill character with white
    }
    y++;
  }
  
  delay(120);
  
}

For the kind of stuff I do its all line level balanced (not a problem) audio until it hits the amp racks.

For stage 1 I will just attach the rectifier (http://sound.westhost.com/appnotes/an001.htm) to one of the analog inputs and see what happens.

I can generate a known 1Vpp 1K tone and use that to calibrate my inputs either within software or with a preamp circuit of some description.

Thankfully subjective audio quality is irrelevant, its power I intend to measure so the input stage can be reallllly cheap and nasty Or The Easy Way - http://www.electronics-tutorials.ws/diode/diode_6.html as I like to call it. The forward voltage drop will need to be addressed though.

Vpp would have to be calculated from the data, the cutoffs depend on the signal type, if its line level it "should" be 1.0 Vpp at 0dB most European audio kit goes uo to +6dB (around 2.2V) and US kit usually hangs around the +4dB level or 1.7Vpp.

Obviously amplified levels such as those from a typical MP3 players headphone output can go wherever the hell the manufacturer wants (but mostly top out at 4v). Conversely Mic inputs are waaaaay lower.

What could happen is to rectify and smooth the input to the Vpp pins and leave the signal as merely rectified, combining the two. But I think that's an unnecessary over complication.

One thing I have seen mentioned but haven't looked at yet is resetting the voltage range that represents 0-1023 samples.

Apologies if this derails the thread, but at least you have the option of calibrating your meters.

The other problem is how dB relates to impedance and amperage, but I think most of us take the engineers route of good enough.

http://www.daycounter.com/Calculators/RMS-Calculator.phtml

For the Peak to Peak RMS calculation from the raw analog input.

http://www.jneuhaus.com/volts_to_dBm.html has a lookup table (if you wish to go that route) and some fairly simple (in the grand scheme of maths) algorithms.

The one I am looking at is =20*LOG10(Volts_peak_to_peak/SQRT(0.008*Z))

Once I can actually test my code I shall ensure it makes it here.

Don't suppose anyone knows the impedance across the analogue input pins do they?

Interesting, I am endeavouring to perform a similar task (although mine will output to an LCD panel.....mebby) and was wondering where to put the calibration for +0dB. Doing it in software seems the sensible option as it offers the most flexibility.

Cant wait for my hardware to arrive, its kind of frustrating developing even simple test code without something to test it against

Thats a very cool idea Jassper, especially if you could make your molds + plugs on a reprap.

I'll give you that, but at least "servomotors" give you an easy control method.