In teoria, ogni volta che si vuole usare il bus SPI, occorre fare quanto dici:
digitalWrite(SS, LOW);
... però, terminato di usare il bus, occorre poi fare:
digitalWrite(SS, HIGH);
per liberarlo.
Se guardi altre librerie che usano il bus SPI fanno così ... 
Guglielmo
Ho fatto un tentativo ma non sembra accadere nulla...magari provo a scrivere al produttore del modulo.
Lucio
Allora ... continuiamo con il datasheet ...
23.3. SS Pin Functionality
23.3.2. Master Mode
When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the SS pin.
If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI Slave.
If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.
Ora ... nella libreria, riga 108, troviamo:
pinMode(_ss, OUTPUT);
// set SS high
digitalWrite(_ss, HIGH);
... ovvero la prima situazione descritta ed il pin DEVE essere poi gestito dall'applicativo (se ho ben capito).
Guglielmo
Anche io lo capisco così. Quindi lo slave è collegato al pin SS della SPI.
Booh, avevo letto il thread ma ora riparto dall'inizio.
PS: punto fondamentale la sorgente di alimentazione del modulo a 3.3V deve potere erogare la corrente richiesta dal modulo, quindi se è vero che assorbe 120mA la sorgente deve potere erogare una corrente maggiore di 120mA.
Ciao.
Ok, avevo notato anche io questa cosa...ma il pin deve essere portato LOW da qualche parte nella libreria altrimenti sarebbe sbagliato persino l'esempio "sender" (che è quello su cui sto lavorando).
Lucio
Teoricamente l'alimentatore "da breadboard" dovrebbe bastare...inoltre penso proprio che 120 mA li prenda solo quando è in trasmissione altrimenti che vantaggio ci sarebbe ad usare il lora?? 
Lucio
Andrebbe collegato un tester in funzione milliamperometro. Almeno capiamo se il modulo viene almeno alimentato.
Appena riprovato, sul 3.3v del modulo arrivano circa 73.5 mA... che per tenerlo in standby penso bastino (ora ricontrollo il datasheet comunque).
EDIT: ecco qua l'estratto del datasheet, siamo più che all'interno del range.
uint8_t LoRaClass::singleTransfer(uint8_t address, uint8_t value)
{
uint8_t response;
digitalWrite(_ss, LOW);
_spi->beginTransaction(_spiSettings);
_spi->transfer(address);
response = _spi->transfer(value);
_spi->endTransaction();
digitalWrite(_ss, HIGH);
return response;
}
Sembra corretto, abbassa _ss e lo alza alla fine.
uint8_t LoRaClass::readRegister(uint8_t address)
{
return singleTransfer(address & 0x7f, 0x00);
}
Ora devo andare, ma torno.
Ciao.
Ho provato a ricablare tutto senza level shifter o altro, solo arduino e lora...chiaramente non funziona. Solo che non riesco a capire perchè tutto l'internet conosciuto li fa funzionare così "plug&play" e noi siamo qua a provarle tutte senza successo 
Lucio
Lo penso anche io, però stavo leggende il manuale
In sezione 5, parla di un alimentatore da circa 250mA.
Ma credo che questo serva quando va in trasmissione.
L'ho visto anche io...ma poi nel datasheet c'è scritto 97 mA in TX. Poi lo vedo molto esagerato come assorbimento e rimane il fatto che nessuno lo alimenta in quel modo
Non è esagerato, l'alimentatore deve avere capacità di erogare corrente superiore alla richiesta massima. Ora è specificato 97mA in TX e quindi un alimentatore da 150÷250mA.
Ma comunque escludo sia questo al momento il problema.
Invece i nodi GND della 5V e 3.3V devono essere in comune e questo pare ovvio.
Altra cosa, qui si parla di frequenza del bus SPI di 8MHz e che non tutte le board la supportano.
<<The first command will help to change the frequency because some device doesn’t operate at 8MHz frequency and SPI will help to get the new SPI pins.>>
Di default vale questa macro:
#define LORA_DEFAULT_SPI_FREQUENCY 8E6
Ma per la MKR vale:
#define LORA_DEFAULT_SPI_FREQUENCY 200000
Ora non idea a che velocità possa viaggiare il bus spi sulla MEGA.
Comunque c'è il metodo:
void setSPIFrequency(uint32_t frequency);
Mi pare lo si debba chiamare prima di lora.begin().
Ciao.
Dunque ho provato a inserire il metodo per settare la frequenza prima del begin(), compila ma non cambia nulla...
P.S: per ora sto collegando tutto alla uno in modo da escludere potenziali problemi di compatibilità con l'SPI.
Lucio
Senza un analizzatore di stati logici con tanto di decodifica protocollo ... difficilmente se ne esce
Oh, poi, magari è difettoso il modulo o, avendolo alimentato a 5V è già stato danneggiato.
Guglielmo
Vero, ho cercato la riga digitalWrite(_ss, LOW); ed ho visto che effettivamente, nel transfer, lo fa ... m'era sfuggito quel metodo ... 
Guglielmo
Per l'alimentazione io ho sempre dato i 3.3...era solo la logica che andava a 5v.
Analizzatore di stati purtroppo non ce l'ho
Lucio
... non so dirti, magari si è danneggiato, magari no ... senza averlo tra le mani e difficile fare altre ipotesi.
Guglielmo
Come ti ho già detto, su internet le bojate si sprecano e poi ... il modulo lo bruci TU ...
... ecco la RISPOSTA ufficiale sul Developer Portal di semtech.com:
Absolute maximum VDD I/O for the S127x family is also 3.9V, the chip is not 5V tolerant
... vedi un po' tu 
Guglielmo
P.S.: invece di seguire le bojate che sono su youtube ed in altri siti, imparate e leggere bene e studiare i datasheet dei componenti ;)
Uhm a questo punto penso proprio sia proprio questo il problema...mannaggia a questi tutorial stupidi.
Ora provo a prendere dei nuovi moduli, al massimo faccio il reso, e vi aggiorno su che succede.
Per ora grazie mille di tutto!!
Lucio